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

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

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

  regards,

  Dan.