Distributing Address Selection Policy Using DHCPv6
draft-ietf-6man-addr-select-opt-13

I have no objection to the publication of this document.

Is there not a concern that an authenticated DHCP server might use this
mechanism to direct traffic (perhaps to attract traffic) against locally
configured policy?  Presumably the first defence is that the local
policy (i.e., the default policy) can be set to not accept over-ride 
from the DHCP server. Maybe this needs to be made a little clearer in 
the document by strengthening the second paragraph in Section 3 and 
stating it in the Introduction

I have concern about section 3.3

   2: Hosts that use advanced heuristics to deal with multiple received
      policies that are defined outside the scope of this document
      SHOULD use Address Selection options.

   Implementations MAY provide configuration options to enable this
   protocol on a per interface basis.

   Implementations MAY store distributed address selection policies per
   interface.  They can be used effectively on implementations that
   adopt per-application interface selection.

It seems like hosts that are attached to two or more administrative domains really don't want to honor an address selection policy since that itself might be subject too the considerations in the security section.  I would expect that if you got two or more policies you'd would want to ignore them and revert to 3484/6724 (of your vendors preference) behavior whether they're authenticated or not. I suppose as someone applying policy it's not safe to assume that the default behavior will not be used even if you are specifying another one. 

I don't really worry about devices that use send or secure dhcp mechanisms, they're fine probably it's the one's that roam (and by their nature have both the address selection problem) and a more ephemeral relationship to the networks to which they are attached.

Section 2, the definition of prefix-len. I ran out of brain power to think through the implications of this, so I'm asking you all to do so: I worry when I see the definition of an unsigned 8-bit field that says "the value ranges from 0 to 128", and then in the next paragraph it starts talking about doing calculations on that number. Are there any interesting buffer-overflow attacks lurking in there? Do we need specific instructions on what a client implementation should do if it sees a value greater than 128 in there? Maybe it makes no difference, but I wanted to be sure.

Referring to flag A:

The text says:

a client SHOULD NOT automatically add rows to the policy table

and 

automatic row addition SHOULD NOT be performed

which means that the implementation MAY do both of these if it chooses.

I just wanted to check that this was the intended behavior, rather than a MUST NOT, which could be legitimately specified behavior given that this is a new option.

=========

I agree with the comment that the prefix text in section 2 could be improved. Also it is a bit confusing to see reference to an IPv4 address in an IPv6 specification. An inline IPv4 example similar to the IPv6 example would be useful.

=========

We have to get to section 3 to find out that this ST document only describes advisory behavior.  ("This option's concept is to serve as a hint for a node about how to behave in the network. " This should really be much earlier in the text, and I think addresses my confusion about SHOULD NOT.

=========

Update to the comment, sent to the authors on 9/21:

In reading your update to the draft, I realize that I failed to communicate the problem here.   Let me try again.

Assume a host in state A, prior to having received any addr-select options.   Now, the host receives an addr-select option, and moves to state B.   The way the document is currently written, when the information in the addr-select option becomes stale, the host moves to state C, where C != A.   This is because in moving from state A to state B, information was lost.   I think it should move to state A, but in order for that to happen, the document needs to explain the details of the process.   If an implementor follows the text as currently written, the host will not be in state A after the addr-select information received from DHCP becomes stale. 

So while I think the clarification you made to this section in the new version of the draft is good and helpful, it does not actually address the problem I am talking about above.

Old comment:

I think that you intend that the implementation should have a local configuration that is restored when the DHCP configuration expires.   Section 3.1 talks about how to handle local configurations, and section 3.2 talks about how to handle stale configurations, but you don't seem to talk about what to do when the actions taken in section 3.1 are deprecated.   So if in fact you intend that the local configuration be restored when the DHCP-supplied configuration has been deprecated, it would be good to make that clear.

Old DISCUSS position:

From the introduction:

   [RFC6724] describes default algorithms for selecting an address when
   a node has multiple destination and/or source addresses to choose
   from by using an address selection policy.  In Section 2 of RFC 6724,
   it is suggested that the default policy table may be administratively
   configured to suit the specific needs of a site.  This specification
   defines a new DHCPv6 option for such configuration.

There is an important distinction between "administratively configured" and "automatically configured through an unauthenticated remote protocol;" this introduction discusses the two as if they are equivalent, but of course they are not.   I don't think you should use this text from RFC 6724 to motivate this document.   To illustrate the problem I"m talking about, ask yourself this: do you think that the administrator of the Wifi hotspot you connect to in your local coffee shop ought to have administrative privileges on your laptop?

I suggest changing the text to this:

   [RFC6724] describes default algorithms for selecting an address when
   a node has multiple destination and/or source addresses to choose
   from by using an address selection policy.  This specification
   defines a new DHCPv6 option for configuring the default policy table.

You can clear this part of the discuss by convincing me that I am wrong to draw this distinction, or by accepting the proposed new text.

I would appreciate it if you could confirm that you analyzed possible attacks that could be done by influencing the source address selection policy on one interface to draw traffic away from another interface, and concluded that no such attacks were possible.  The issue I'm concerned about would be for example a DHCP-supplied configuration preventing a VPN from working properly, or capturing traffic intended for the VPN, or else a DHCP-supplied configuration drawing traffic from one interface to another.

I sat down and thought about it for a bit tonight and the attacks that I thought of don't seem to be possible, so I'm assuming the answer to this question is "yes, we thought about it, and no, there isn't an issue here."   So you can clear this part of the discuss simply by saying that, if it is in fact the case.   Otherwise, I'd appreciate it if you could think about it and report back, because you probably understand the problem space better than I do.