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

From: "Dan Harkins" <[email-masked]>
Date: Tue, 21 May 2013 12:22:47 -0700 (PDT)

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.

  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? 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? This whole section (3.3) screams out for some normative
language since it sounds like it refers to behavioral changes on the
node.

  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.

  An appendix with examples would be most helpful!

  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.

  regards,

  Dan.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 28 May 2013 15:25:01 +0900

Hi Dan,
I appreciate your review.

Comments below.

2013/5/22 Dan Harkins <[email-masked]>

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

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 ?

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

Do you mean this section should have more SHOULDs and MUSTs ?
If so, on which part do you think should we put ?

> recipient, means that a canonical representation of "label" has to

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 ?

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