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

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