Re: [6MAN] I-D Action: draft-ietf-6man-addr-select-opt-02.txt

[Ray Hunter <[e-mail]>]

Answers in line

Arifumi Matsumoto wrote:
> Ray,
>
> thank you for your comments.
>
> On 2012/02/22, at 2:56, Ray Hunter wrote:
>
>    
>> I have read draft-ietf-6man-addr-select-opt-03. I support this work. Thanks.
>>
>> Some comments.
>>
>> 1) I find Section 4.3 unsatisfactory. In highly-mobile devices, the status "single-homed" and "only one upstream line" is time dependent. A highly-mobile device may have a semi-permanent 4G uplink, and a temporary wifi uplink dependent on the user's current location. Whether a new Address Selection Policy table is installed or not should not depend primarily on the order that the interfaces are brought up.
>>      
>
> If we think about the routing table, the entries related to a certain network interface will also be added and deleted, when the interface goes up and down.
>
> So, it seems to me that this issue is not too new, or strange for implementors.
>
>    
My concern is that the guidance in this draft is not correctly 
formulated IMHO.

I agree that incorrect use of the addr-select-opt may lead to a security 
issue, in that node-global behavior is affected by the proposed option. 
Thus traffic intended for interface 1/ network 1 may be misdirected to 
interface 2 / network 2 by receiving an address-selection policy option 
from network 2.

However, this security risk is not directly correlated to the number of 
active interfaces at the time the policy is received IMHO.

In some situations I can think of, you may well want to trust a 
particular DHCPv6 server to configure a link address on an interface, 
plus maybe some hints about which name servers or time servers to use to 
set up an initial connection, but not to set a policy for which address 
ranges and hence interfaces to select for which traffic. Even receiving 
policy information over one active interface may not be considered a 
reasonable risk by some e.g. if a second interface is brought up later 
(e.g. a tunnel), and (some of) the old policy information from the first 
interface is not flushed because that first interface is still up and 
the second interface does not provide a policy update.

In a corporate environment, it may well be desirable to receive policy 
updates on multiple interfaces without having to explicitly configure 
this, because all updates ultimately have been derived from a trusted AS 
source.

Therefore I think the risk is more closely related to the consistency 
and provenance of the DHCPv6 derived address selection policy 
information i.e. whether the device is receiving the option from more 
than one Autonomous System simultaneously, or from an AS source that is 
not trusted.

I'd be happy if the draft contained a warning of the risk, without 
getting into details of how to mitigate the risk in implementation.
>> 2) Suggest splitting transport of policy/configuration information from actual use of the policy/configuration information by the end node. I'm thinking of how routers may have multiple sources of routing information (derived from various sources: static, RIPng, OSPFv3) but they may only install subsets of the total known information into the single active forwarding table using local policy configuration concepts such as Administrative Distance and locally defined route filters.
>>      
>
> Do you suggest splitting them into different documents, or just defining the transport information format and leaving others to implementation dependent ?
> I do not see much value in just dividing this into two documents. It just makes it troublesome to understand this mechanism.
>
> Regarding the latter case,
> IMO, this mechanism is so new, and no operational experiences are gained by administrators, implementors, and so on. So, we first have to propose the expected /recommended way to use this mechanism. If you find the current specification goes beyond recommendation in some points, please tell it to me.
>
>    
I humbly suggest considering which WG is appropriate for defining which 
portion of the overall mechanism. There seems to be a very large overlap 
with MIF, and one possible way to handle this would be to have the pure 
transport of the option defined in your 6man draft (which I guess could 
be pretty non-contentious), and defining the use of the information in 
the MIF workflow. Another option might be simply to co-post the draft to 
the MIF WG.

<snip>

> I think it is a matter of implementation, and common for several other DHCPv6 options.
>
> It may be helpful for implementors, but this document should not be the right place for this generic issue.
>
> Thanks !
>
>    
Agree. This is off topic for your draft, but maybe someone will take up 
the generic challenge in another draft.

<snip>

regards,
RayH