Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt

[Arifumi Matsumoto <[e-mail]>]

Hi,

did my previous e-mail get to you all ?


2013/5/28 Arifumi Matsumoto <[e-mail]>

> Hi Dan,
> I appreciate your review.
>
> Comments below.
>
> 2013/5/22 Dan Harkins <[e-mail]>
>
>>
>>   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.
>
> 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 ?
>
> If not, splitting the flag into another new sub-option makes sense to you ?
>
>
>>
>>   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.
>
>
>
>> 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.
>
>
>> 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 ?
>
>
>>
>>   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.
>
>
>>   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 ?
>
>
>>
>>   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 ?
>
> Best regards,
>
>
>>
>>   regards,
>>
>>   Dan.
>>
>>
>>
>