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

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

  Hi Arifumi,

  It looks fine. Thanks.

  regards,

  Dan.

On Wed, June 26, 2013 9:59 pm, Arifumi Matsumoto wrote:
> Hi,
>
> then, let me submit this version today.
> Dan, please comment on it, if you have any.
>
> Thanks.
>
>
> 2013/6/20 Arifumi Matsumoto <[e-mail]>
>
>> Dan,
>>
>> this is diff from the previous version, as requested by Ole.
>> https://bitbucket.org/arifumi/draft-addr-select-opt/diff/draft-ietf-6man-
>> addr-select-opt.txt?diff2=2e7efc634b5a&at=master
>>
>> Thanks.
>>
>>
>>
>> 2013/6/17 Arifumi Matsumoto <[e-mail]>
>>
>>> I attached a rev candidate.
>>> Hope this solves the issues pointed by Dan.
>>>
>>> Thank you very much.
>>>
>>>
>>> 2013/6/13 Ole Troan <[e-mail]>
>>>
>>>> Dan,
>>>>
>>>> >  Yes, I am fine with Arifumi's clarification. Thanks.
>>>>
>>>> splendid, thanks for the help!
>>>>
>>>> Best regards,
>>>> Ole
>>>>
>>>> >> 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.
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>
>>
>