Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt
"Dan Harkins" <dharkins@lounge.org> Wed, 05 June 2013 18:54 UTC
Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A0321F9BD3; Wed, 5 Jun 2013 11:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLGzOkyqIvMD; Wed, 5 Jun 2013 11:54:35 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC2C21F9C04; Wed, 5 Jun 2013 11:54:19 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 63079A888008; Wed, 5 Jun 2013 11:54:02 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 5 Jun 2013 11:54:02 -0700 (PDT)
Message-ID: <db97e55490833ace9abd5eefcb96b637.squirrel@www.trepanning.net>
In-Reply-To: <CABTuw1CX6gAMCLNzPZyLyOfKCgWbWw7jk9vmPqSR4vXLUdcW=Q@mail.gmail.com>
References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> <CABTuw1BWw6xxdo9zmQaVc3ceq1k4mGOOaZgEixSwgctuvYKc2w@mail.gmail.com> <CABTuw1CX6gAMCLNzPZyLyOfKCgWbWw7jk9vmPqSR4vXLUdcW=Q@mail.gmail.com>
Date: Wed, 05 Jun 2013 11:54:02 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Arifumi Matsumoto <arifumi@nttv6.net>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" <draft-ietf-6man-addr-select-opt.all@tools.ietf.org>, secdir@ietf.org, iesg@ietf.org, Arifumi Matsumoto <arifumi@nttv6.net>
Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2013 18:55:28 -0000
Hi, On Wed, June 5, 2013 6:51 am, Arifumi Matsumoto wrote: > Hi, > > did my previous e-mail get to you all ? No, it didn't; thanks for resending. > 2013/5/28 Arifumi Matsumoto <arifumi@nttv6.net> > >> Hi Dan, >> I appreciate your review. >> >> Comments below. >> >> 2013/5/22 Dan Harkins <dharkins@lounge.org> >> >>> >>> Hello, >>> >>> I have reviewed draft-ietf-6man-addr-select-opt as part of the >>> security directorate's ongoing effort to review all IETF documents >>> being processed by the IESG. These comments were written primarily >>> for the benefit of the security area directors. Document editors and >>> WG chairs should treat these comments just like any other last call >>> comments. >>> >>> draft-ietf-6man-addr-select-opt defines address selection options >>> for DHCPv6 that allow a network administrator to effect some >>> control over address selection behavior of nodes on their sites. >>> >>> This sounds like a reasonably straightforward problem but as I >>> read the draft it seemed like it might be have interoperability issues. >>> I don't believe this draft is ready for advancement until these issues >>> are resolved. >>> >>> For instance, while I think I understand the policy override of RFC >>> 6724, having the Automatic Row Additions Flag be part of the address >>> selection options seems problematic. If it is set to zero, then what >>> are >>> the semantics of such a message? "Here's an address selection option >>> but don't you dare use it!"? What is the point? Me, as a node, can have >>> this as part of my policy state which would allow me to ignore such >>> an update but to have the bit be part of the option to update does >>> not seem to make much sense. The semantics of the message needs >>> to be explained much more clearly, or the bit needs to be removed >>> from the message. >>> >> >> If A flag is zero, it means Automatic Row Addition is indicated not to >> perform. >> If A flag is 1, it means it is up to the node. So what is the purpose of sending someone a row for addition and saying "do not perform addition"? >> Even in the latter case, the Address Selection Option may contain other >> information to the node, such as the policy table and other flags. >> >> Make sense ? Not really. So what's the semantics of this other information if the flag is set to zero? "Here's some other stuff but don't use it either"? >> If not, splitting the flag into another new sub-option makes sense to >> you ? Why not just get rid of this flag. It's always "up to the node" whether it is willing to modify its own resources or not. >> >>> >>> Section 3.3 says, "Even if the received policy from one source is >>> merged with one from another source, the effect of both policy are >>> more or less changed." I don't understand how both policies are >>> changed. And what does "more or less" mean? >> >> >> I think that a policy table has its own unique meaning. Even single >> insertion/deletion from the table makes the table different. >> >> For example, when adding a line, from one source, to the default policy >> table below, >> >> Prefix Precedence Label >> ::1/128 50 0 >> ::/0 40 1 >> ::ffff:0:0/96 35 4 >> 2002::/16 30 2 >> 2001::/32 5 5 >> fc00::/7 3 13 >> ::/96 1 3 >> fec0::/10 1 11 >> 3ffe::/16 1 12 >> >> makes >> >> Prefix Precedence Label >> ::1/128 50 0 >> ::/0 40 1 >> ::ffff:0:0/96 35 4 >> 2002::/16 30 2 >> + 2003::/16 10 6 >> 2001::/32 5 5 >> fc00::/7 3 13 >> ::/96 1 3 >> fec0::/10 1 11 >> 3ffe::/16 1 12 >> >> In this case, the prefix 2003::/16 has lower precendence than the >> default >> policy table. And, the table contains a lot of policy that is not >> intended >> by >> the source who deliver single line of policy. If I add lines from one table to another I only change the latter. The former is not changed. And "more or less" is too vague. So how about rewriting that sentence to be: "Merging received policy into an existing policy changes the existing policy." although this statement seems so self-evident as to suggest just getting rid of the problematic text from 3.3 altogether. >> >>> 3.3 also says, >>> "It also should be noted that absence of the distributed policy from a >>> certain network interface should not be treated as absence of policy >>> itself, because it may mean preference for the default address >>> selection policy." So I use the default address selection policy then, >>> is that it? >> >> >> I mean, there is no way to tell the network with no policy distribution >> prefers default policy, or does not care about it. >> The conclusion is "using the default policy should be safe", though. Then I think you should say that directly. >> >>> This whole section (3.3) screams out for some normative >>> language since it sounds like it refers to behavioral changes on the >>> node. >>> >> >> Do you mean this section should have more SHOULDs and MUSTs ? >> If so, on which part do you think should we put ? How about: "In the absence of distributed policy for a certain network interface, the default address selection policy SHOULD be used." And get rid of the single SHOULD in the existing text that is followed by 1) and 2) and make two separate SHOULD statements: "A single-homed host SHOULD use default address selection options. Hosts that use advanced heuristics that are defined outside the scope of this document SHOULD use default address selection options." You say, "The above restrictions do not preclude implementations from providing configuration options to enable this option on a certain network interface." which could be changed to "Implementations MAY provide configuration options to enable this protocol on a per interface basis." if that is your intent. >>> >>> There is an "Implementation Consideration" mentioning that the >>> label is passed as an unsigned integer. But it then goes on to say, >>> "DHCPv6 clients SHOULD convert this label to a representation >>> appropriate for the local implementation (e.g., string)." This has >>> interoperability implications because it is not solely a local matter. >>> The node may represent these things differently than the network >>> administrator and the preference will not be done properly. RFC 6724 >>> does not really define what the label is from what I can tell. It's >>> used to just allow for policies to prefer a particular source address, >>> S, with a particular destination address, D, if "Label(S) = Label(D)". >>> But to pass a value over a network, and have it be used by the >>> recipient, means that a canonical representation of "label" has to >>> be defined. >>> >> >> Maybe, I don't understand your point quite well. >> As far as the one-to-one mapping in a node is performed between an >> unsinged integer and representation format, I think there will not arise >> interoperability issue, such that a policy has different meaning >> depending >> on a receiving host. I'm saying this has an impact on interoperability because there's no way to ensure that this option will be processed correctly. There is no way for the sender of this option to know how the recipient is representing labels locally and therefore there is no way for the sender to properly convey his intent in the option he sends. I may have existing policies where Label(A) = 0x31 and another where Label(B) = 0x01. Now I get an label in my address selection option that is an unsigned integer of the value 0x01. Should I convert it to a string, as the text says I SHOULD? Should I use ASCII? So then it will match Label(A)? Or should I use it directly and it therefore should match Label(B). I just don't think you can mention conversion here. The field has to be treated as an opaque blob or some canonical representation MUST be defined. >>> An appendix with examples would be most helpful! >>> >> >> RFC 6724 has a lot of examples for policy table. >> Do you think we need other examples, or just same ones ? Since this draft is about updating, or modifying, the policy table it would be nice to see a sample Address Selection Option with at least one, and preferably more, Address Selection Policy Table options and what receipt of that message would be to a sample policy table. Show a before policy table, the message that modifies it, and an after policy table. >>> >>> Spelling nit: section 3.1 "The choice a SHOULD be default, as far as >>> the policy table is not configured by the user." There's an extra >>> word in there somewhere, or maybe there's some words missing, >>> it's hard to understand what is being implied. >>> >> >> It means the choice called "a" below should be default. >> Maybe using parenthesis (a) makes it clearer ? That make more sense. Suggest removing the article then too. So make it "Choice (a) SHOULD be default...." regards, Dan.
- [secdir] secdir review of draft-ietf-6man-addr-se… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Ole Troan
- Re: [secdir] secdir review of draft-ietf-6man-add… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Ole Troan
- Re: [secdir] secdir review of draft-ietf-6man-add… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-6man-add… Ole Troan
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Arifumi Matsumoto
- Re: [secdir] secdir review of draft-ietf-6man-add… Dan Harkins