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

[Arifumi Matsumoto <[e-mail]>]

Hi,

2013/6/12 Dan Harkins <[e-mail]>

>
>   Hi Ole,
>
> On Tue, June 11, 2013 2:24 am, Ole Troan wrote:
> > Dan,
> >
> > 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.
>

In my understanding,
- RFC 6724 defines a knob for switching automatic row addition.
- addr-select-opt defines a knob for switching whether accepting automatic
row addition flag delivered or not.

and, if the second knob is switched to "accept", then the first knob is
overridden by a delivered flag.

This is common case in moderen user OS settings, such that the DNS server
configuration can be
switched to automatic(delivered from network), or to locally configured to
some value.



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

As I mentioned in the previous e-mail, that I sent 10 June,
when this A flag is turned on, the DHCP option should not carry policy
table,
and a receiver should ignore it, which I have to add some text in the rev.

Thanks.


>
>   regards,
>
>   Dan.
>
>
>