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

[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.
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>