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

[Arifumi Matsumoto <[e-mail]>]

Dan,

to summarize my statement, a host's behavior will look like:

i) a host is configured to accept A-flag and policy table from network
  a) A-flag in DHCP option is 0 (disable automatic row addition)
    1) DHCP option includes policy table
       host should disable automatic row addition, and use delivered policy
table.
    2) DHCP option does not include policy table
       host should disable automatic row addition. no change on host's
policy table.

  b) A-flag in DHCP option is 1 (no effect on host's A-flag)
    1) DHCP option includes policy table
        host should disable automatic row addition, and use delivered
policy table.
    2) DHCP option does not include policy table
        host does nothing.

ii) a host is configured not to accept A-flag nor policy table from network
        host does nothing.

Hope this helps.

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