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

[Ole Troan <[e-mail]>]

Dan,

apologies for the delay, I discussed this directly with Arifumi, and I hope his latest message clarifies the issue.

to rephrase in my words;
OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to disable automatic row addition)
and to carry policy table options.
the A-flag is a hint to the host to disable automatic row addition.
if OPTION_ADDRSEL contains policy table options the A-flag is redundant.
(as policy table options and the A-flag are incompatible).

if you are fine with this, I will ask the authors to update the draft to make this behaviour explicit.

Best regards,
Ole

>> let me chime in as the document shepherd.
>> (thank you very much for the thorough comments by the way).
>> 
>>> 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.
>> 
>> my reading of the meaning of the A flag is a little different. (I have
>> cc'ed the authors of rfc6724 for confirmation.)
>> 
>> an implementation of RFC6724 may automatically add entries in the policy
>> table based on addresses configured on the node.
>> e.g. the node has an interface with a ULA address.
>> 
>> RFC6724 also says:
>>   An implementation SHOULD provide a means (the Automatic Row Additions
>> flag) for an administrator to disable
>>   automatic row additions.
> 
>  That makes perfect sense. A client implementation SHOULD provide a
> means to disable automatic row additions. So it has some knob that can
> be turned on or off locally that would allow for update of its policy table
> by receiving policy options (enable) or forbid received policy options from
> updating the policy table (disable).
> 
>> the A-flag in draft-ietf-6man-addr-select-opt provides the means.
> 
>  So this is where I'm confused. The sender of the policy option should
> not have the ability to control the knob that an implementation added
> locally to satisfy RFC 6724. If a client implementation sets its knob to
> "disable" then it forbids policy option updates to its policy table. It
> shouldn't inspect the received option update to decide whether it
> should override the setting of its local knob.
> 
>  This seems like a security issue to me. There's a reason why an
> implementation would choose to disable updates of its policy table
> and allowing the sender of policy updates to override that seems
> wrong.
> 
>> it does not affect the policy entries that is contained in the DHCP
>> option.
>> the A-flag only affects the RFC6724 behaviour of adding entries based on
>> address configuration on the node.
> 
>  Again, according to the draft a message can be received by a client
> implementation that provides policy update options to its policy table
> with semantics of "you SHOULD NOT use these!" So what is the point
> of sending that message? Why not just refrain from sending the message
> if that's what the message is?
> 
>  Would you ever tell someone, "disregard what I am about to tell you"? I
> can't see why. And that's what the semantics of this message seem to be.