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

[Arifumi Matsumoto <[e-mail]>]

Hi,


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

>
>   Hi,
>
> On Tue, June 11, 2013 11:55 pm, Arifumi Matsumoto wrote:
> > 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.
>
>   So you're saying that the local knob can be overridden by the bit in
> the message? That begs the question: why would one send a message with
> the "delivered flag" set to "don't accept", meaning "don't accept this
> update"?
> How is that different than omitting this "don't accept" information from
> the
> message in the first place?
>

No, these *two* knobs are *local*.
So, "don't accept" cannot be delivered over network.
I failed to mention about it. Sorry for confusion.

This misunderstanding lead to the following further confusions.
Sorry about that.

Regards,


>
> > 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.
>
>   But why would the network set an option indicating that the recipient
> should
> not use this configuration"? If the recipient has a knob indicating that
> local
> policy cannot be updated then the bit has no effect and if the recipient
> has a
> knob indicating that the policy can be updated then setting the the bit in
> the
> message should be meaningless.
>
> >>
> >> > 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.
>
>   But why would a server send an address selection option that said, "don't
> use this"? Once again, it makes no sense to have these semantics.
>
>   If you notice, this question seems to be repeated over and over yet I
> have
> not yet received an answer why or an statement that I don't understand
> the semantics of the message. So what is it? Do I not understand (in which
> you should explain exactly why) or is this message meaningless (in which
> case why is it part of your draft)?
>
>   regards,
>
>   Dan.
>
>
>