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

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 5 Jun 2013 22:51:09 +0900

Hi,

did my previous e-mail get to you all ?

2013/5/28 Arifumi Matsumoto <[email-masked]>

> Hi Dan,
> I appreciate your review.
>
> Comments below.
>
> 2013/5/22 Dan Harkins <[email-masked]>
>
>>
>>   Hello,
>>
>>   I have reviewed draft-ietf-6man-addr-select-opt as part of the
>> security directorate's  ongoing effort to review all IETF documents
>> being processed by the IESG.  These comments were written primarily
>> for the benefit of the  security area directors.  Document editors and
>> WG chairs should treat these comments just like any other last call
>> comments.
>>
>>   draft-ietf-6man-addr-select-opt defines address selection options
>> for DHCPv6 that allow a network administrator to effect some
>> control over address selection behavior of nodes on their sites.
>>
>>   This sounds like a reasonably straightforward problem but as I
>> read the draft it seemed like it might be have interoperability issues.
>> I don't believe this draft is ready for advancement until these issues
>> are resolved.
>>
>>   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.
>>
>
> If A flag is zero, it means Automatic Row Addition is indicated not to
> perform.
> If A flag is 1, it means it is up to the node.
>
> Even in the latter case, the Address Selection Option may contain other
> information to the node, such as the policy table and other flags.
>
> Make sense ?
>
> If not, splitting the flag into another new sub-option makes sense to you ?
>
>
>>
>>   Section 3.3 says, "Even if the received policy from one source is
>> merged with one from another source, the effect of both policy are
>> more or less changed." I don't understand how both policies are
>> changed. And what does "more or less" mean?
>
>
> I think that a policy table has its own unique meaning. Even single
> insertion/deletion from the table makes the table different.
>
> For example, when adding a line, from one source, to the default policy
> table below,
>
>       Prefix        Precedence Label
>       ::1/128               50     0
>       ::/0                  40     1
>       ::ffff:0:0/96         35     4
>       2002::/16             30     2
>       2001::/32              5     5
>       fc00::/7               3    13
>       ::/96                  1     3
>       fec0::/10              1    11
>       3ffe::/16              1    12
>
> makes
>
>       Prefix        Precedence Label
>       ::1/128               50     0
>       ::/0                  40     1
>       ::ffff:0:0/96         35     4
>       2002::/16             30     2
> +     2003::/16             10    6
>       2001::/32              5     5
>       fc00::/7               3    13
>       ::/96                  1     3
>       fec0::/10              1    11
>       3ffe::/16              1    12
>
> In this case, the prefix 2003::/16 has lower precendence than the default
> policy table. And, the table contains a lot of policy that is not intended
> by
> the source who deliver single line of policy.
>
>
>
>> 3.3 also says,
>> "It also should be noted that absence of the distributed policy from a
>> certain network interface should not be treated as absence of policy
>> itself, because it may mean preference for the default address
>> selection policy." So I use the default address selection policy then,
>> is that it?
>
>
> I mean, there is no way to tell the network with no policy distribution
> prefers default policy, or does not care about it.
> The conclusion is "using the default policy should be safe", though.
>
>
>> This whole section (3.3) screams out for some normative
>> language since it sounds like it refers to behavioral changes on the
>> node.
>>
>
> Do you mean this section should have more SHOULDs and MUSTs ?
> If so, on which part do you think should we put ?
>
>
>>
>>   There is an "Implementation Consideration" mentioning that the
>> label is passed as an unsigned integer. But it then goes on to say,
>> "DHCPv6 clients SHOULD convert this label to a representation
>> appropriate for the local implementation (e.g., string)." This has
>> interoperability implications because it is not solely a local matter.
>> The node may represent these things differently than the network
>> administrator and the preference will not be done properly. RFC 6724
>> does not really define what the label is from what I can tell. It's
>> used to just allow for policies to prefer a particular source address,
>> S, with a particular destination address, D, if "Label(S) = Label(D)".
>> But to pass a value over a network, and have it be used by the
>> recipient, means that a canonical representation of "label" has to
>> be defined.
>>
>
> Maybe, I don't understand your point quite well.
> As far as the one-to-one mapping in a node is performed between an
> unsinged integer and representation format, I think there will not arise
> interoperability issue, such that a policy has different meaning depending
> on a receiving host.
>
>
>>   An appendix with examples would be most helpful!
>>
>
> RFC 6724 has a lot of examples for policy table.
> Do you think we need other examples, or just same ones ?
>
>
>>
>>   Spelling nit: section 3.1 "The choice a SHOULD be default, as far as
>> the policy table is not configured by the user." There's an extra
>> word in there somewhere, or maybe there's some words missing,
>> it's hard to understand what is being implied.
>>
>
> It means the choice called "a" below should be default.
> Maybe using parenthesis (a) makes it clearer ?
>
> Best regards,
>
>
>>
>>   regards,
>>
>>   Dan.
>>
>>
>>
>

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 5 Jun 2013 11:54:02 -0700 (PDT)

Hi,

> did my previous e-mail get to you all ?

  No, it didn't; thanks for resending.

>> If A flag is 1, it means it is up to the node.

  So what is the purpose of sending someone a row for addition
and saying "do not perform addition"?

>> information to the node, such as the policy table and other flags.

  Not really. So what's the semantics of this other information if the
flag is set to zero? "Here's some other stuff but don't use it either"?

>> If not, splitting the flag into another new sub-option makes sense to

  Why not just get rid of this flag. It's always "up to the node" whether it
is willing to modify its own resources or not.

>> For example, when adding a line, from one source, to the default policy

  If I add lines from one table to another I only change the latter.
The former is not changed. And "more or less" is too vague. So how
about rewriting that sentence to be:

      "Merging received policy into an existing policy changes
       the existing policy."

although this statement seems so self-evident as to suggest just
getting rid of the problematic text from 3.3 altogether.

>> The conclusion is "using the default policy should be safe", though.

  Then I think you should say that directly.

>> If so, on which part do you think should we put ?

  How about: "In the absence of distributed policy for a certain network
interface, the default address selection policy SHOULD be used." And
get rid of the single SHOULD in the existing text that is followed by 1)
and 2) and make two separate SHOULD statements: "A single-homed
host SHOULD use default address selection options. Hosts that use
advanced heuristics that are defined outside the scope of this document
SHOULD use default address selection options."

  You say, "The above restrictions do not preclude implementations from
providing configuration options to enable this option on a certain network
interface." which could be changed to "Implementations MAY provide
configuration options to enable this protocol on a per interface basis."
if that is your intent.

>> interoperability issue, such that a policy has different meaning

  I'm saying this has an impact on interoperability because there's no
way to ensure that this option will be processed correctly. There is no
way for the sender of this option to know how the recipient is
representing labels locally and therefore there is no way for the sender
to properly convey his intent in the option he sends.

  I may have existing policies where Label(A) = 0x31 and another
where Label(B) = 0x01. Now I get an label in my address selection option
that is an unsigned integer of the value 0x01. Should I convert it to a
string, as the text says I SHOULD? Should I use ASCII? So then it will
match Label(A)? Or should I use it directly and it therefore should
match Label(B).

  I just don't think you can mention conversion here. The field has to
be treated as an opaque blob or some canonical representation MUST
be defined.

>> Do you think we need other examples, or just same ones ?

  Since this draft is about updating, or modifying, the policy table
it would be nice to see a sample Address Selection Option with at
least one, and preferably more, Address Selection Policy Table
options and what receipt of that message would be to a sample
policy table. Show a before policy table, the message that modifies
it, and an after policy table.

>> Maybe using parenthesis (a) makes it clearer ?

  That make more sense. Suggest removing the article then too. So
make it "Choice (a) SHOULD be default...."

  regards,

  Dan.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 10 Jun 2013 19:51:29 +0900

Hi,

thank you for your reply.
comments below.

2013/6/6 Dan Harkins <[email-masked]>

>   No, it didn't; thanks for resending.

I will resend an e-mail sooner, this time :)

> and saying "do not perform addition"?

No, the distributed policy table is not for addition, but for replacement.

> is willing to modify its own resources or not.

I missed one point.

Regarding flag A, it is hard to insert automatically some specific prefixes
into the distributed policy table. This is for the reason mentioned in
policy
merging issue. So, this flag should be used, only when the distributed
option does not include policy table, which should be mentioned in this
draft.

And, when the option does not include policy table, this flag A can be
used to indicate whether a host can insert ULA and 6to4, to the default
policy table.

> getting rid of the problematic text from 3.3 altogether.

I agree with removing the following sentence, because it looks redundant.

   Even if the received policy from one source is merged with one from
     another source, the effect of both policy are more or less changed.

>   Then I think you should say that directly.

Ok, I'll change the text accordingly.

> configuration options to enable this protocol on a per interface basis."

Okay. Looks nice.

> be treated as an opaque blob or some canonical representation MUST

I think what you describe here is conflict with local policy.

As 3.1 mentioned, the distributed policy will replace local policy, or
will not be used at all.

So, as far as policy merge does not happen, conflict also will not happen.

> it, and an after policy table.

Okay, I'll include some in the rev.

> make it "Choice (a) SHOULD be default...."

Looks good.

Thanks.

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Jun 2013 11:24:52 +0200

Dan,

let me chime in as the document shepherd.
(thank you very much for the thorough comments by the way).

> to be explained much more clearly, or the bit needs to be removed

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.

the A-flag in draft-ietf-6man-addr-select-opt provides the means.

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.

cheers,
Ole

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 11 Jun 2013 09:31:56 -0700 (PDT)

Hi Ole,

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

  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.

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

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 12 Jun 2013 15:55:02 +0900

Hi,

2013/6/12 Dan Harkins <[email-masked]>

> and allowing the sender of policy updates to override that seems

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.

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

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 12 Jun 2013 01:06:00 -0700 (PDT)

Hi,

On Tue, June 11, 2013 11:55 pm, Arifumi Matsumoto wrote:
>> >    An implementation SHOULD provide a means (the Automatic Row
>> Additions
>> > flag) for an administrator to disable
>> >    automatic row additions.
>>

  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?

> switched to automatic(delivered from network), or to locally configured to

  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.

>> > the A-flag only affects the RFC6724 behaviour of adding entries based
>> on
>> > address configuration on the node.
>>

  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.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 12 Jun 2013 17:17:35 +0900

Hi,

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

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 12 Jun 2013 18:56:00 +0900

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.

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 12:06:34 +0200

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

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 12 Jun 2013 20:17:31 -0700 (PDT)

Hi Ole,

  Yes, I am fine with Arifumi's clarification. Thanks.

  regards,

  Dan.

On Wed, June 12, 2013 3:06 am, Ole Troan wrote:
> 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;

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Jun 2013 10:45:31 +0200

Dan,

>  Yes, I am fine with Arifumi's clarification. Thanks.

splendid, thanks for the help!

Best regards,
Ole

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 17 Jun 2013 20:27:39 +0900

I attached a rev candidate.
Hope this solves the issues pointed by Dan.

Thank you very much.

2013/6/13 Ole Troan <[email-masked]>

> >> OPTION_ADDRSEL is used to carry the A-flag (the hint to a host to
> disable
> >> automatic row addition)

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 20 Jun 2013 13:31:28 +0900

Dan,

this is diff from the previous version, as requested by Ole.
https://bitbucket.org/arifumi/draft-addr-select-opt/diff/draft-ietf-6man-
addr-select-opt.txt?diff2=2e7efc634b5a&at=master

Thanks.

2013/6/17 Arifumi Matsumoto <[email-masked]>

>> >> if you are fine with this, I will ask the authors to update the draft
>> to
>> >> make this behaviour explicit.
>> >>
>> >> Best regards,
>> >> Ole
>> >>

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 27 Jun 2013 13:59:46 +0900

Hi,

then, let me submit this version today.
Dan, please comment on it, if you have any.

Thanks.

2013/6/20 Arifumi Matsumoto <[email-masked]>

>>> >>>>> selection options seems problematic. If it is set to zero, then
>>> what
>>> >>>>> are
>>> >>> by receiving policy options (enable) or forbid received policy
>>> options
>>> >>> from

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 27 Jun 2013 09:10:26 -0700 (PDT)

Hi Arifumi,

  It looks fine. Thanks.

  regards,

  Dan.

On Wed, June 26, 2013 9:59 pm, Arifumi Matsumoto wrote:
>>>> >>>>> but don't you dare use it!"? What is the point? Me, as a node,
>>>> can
>>>> >>>>> have
>>>> >>> be turned on or off locally that would allow for update of its
>>>> policy
>>>> >>> table
>>>> >>> "disable" then it forbids policy option updates to its policy
>>>> table.
>>>> It
>>>> >>>> it does not affect the policy entries that is contained in the
>>>> DHCP
>>>> >>>> option.
>>>> >>> can't see why. And that's what the semantics of this message seem
>>>> to
>>>> be.
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>
>>
>