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

["Dan Harkins" <[e-mail]>]

  Hi Ole,

  Yes, I am fine with Arifumi's clarification. Thanks.

  regards,

  Dan.

On Wed, June 12, 2013 3:06 am, Ole Troan wrote:
> 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.
>
>
>
>