Subject: 6MAN WG Adoption Call: draft-gont-6man-nd-opt-validation-01

From: Ole Troan <[email-masked]>
Date: Fri, 12 Dec 2014 13:12:20 +0100

This message starts a two week 6MAN Working Group Last Call on adopting:

      Title           : Validation of IPv6 Neighbor Discovery Options
      Authors         : F. Gont, R. Bonica, W. Liu
      Filename        : draft-gont-6man-nd-opt-validation-01
      Pages           : 15
      Date            : 2014-10-21

      https://tools.ietf.org/html/draft-gont-6man-nd-opt-validation-01

as a working group item. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on December 26, 2014.

Regards,

Bob Hinden & Ole Trøan

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 12 Dec 2014 22:23:21 +0000 (UTC)

Hi,

I support the working group adopting this draft.

Regards,
Mark.

----- Original Message -----
> From: Ole Troan <[email-masked]>
> To: 6man WG <[email-masked]>
> Cc: 6man Chairs <[email-masked]>
> Sent: Friday, 12 December 2014, 23:12
> Subject: 6MAN WG Adoption Call: draft-gont-6man-nd-opt-validation-01
> 
>T his message starts a two week 6MAN Working Group Last Call on adopting:
> 
> as a working group item. Substantive comments and statements of support for 
> adopting this document should be directed to the mailing list.  Editorial 
> suggestions can be sent to the authors.  This adoption call will end on December 
> 26, 2014.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan
>

---

From: Bill Shelton <[email-masked]>
Date: Tue, 16 Dec 2014 18:47:01 +0000

Support.

- Bill

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Friday, December 12, 2014 7:12 AM
> To: 6man WG
> Cc: 6man Chairs
> as a working group item. Substantive comments and statements of 
> support for adopting this document should be directed to the mailing 
> list.  Editorial suggestions can be sent to the authors.  This 
> adoption call will end on December 26, 2014.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan
>

---

From: Ray Hunter <[email-masked]>
Date: Tue, 16 Dec 2014 22:09:31 +0100

Support.

> ---Original Message-----
> Bob Hinden&  Ole Trøan
> Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6
> Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6

-- 
Regards,
RayH

---

From: Tomoyuki Sahara <[email-masked]>
Date: Wed, 17 Dec 2014 10:36:39 +0900

I support adoption and have a comment.

In Section 10 (about RDNSS option) of this document:

>    The Lifetime field specifies the maximum time in seconds that a node
>    may use the IPv6 addresses included in the option for name
>    resolution, with a value of 0 indicating that they can no longer be
>    used.  If the Lifetime field is not equal to 0, it MUST be at least
>    1800 (MinRtrAdvInterval) and at most 3600 (2*MaxRtrAdvInterval).  If
>    the RDNSS option does does not pass this validation check, it MUST be
>    ignored.  However, the rest of the ND message MAY be processed.

The maximum value of the lifetime field should be larger.

Although the description above is consistent with RFC6106 (says the value
of lifetime field SHOULD be <= 2*MaxRtrAdvInterval in section 5.1), it is
too short because only a few packet losses removes DNS server information
from hosts on the subnet as described in
draft-gont-6man-slaac-dns-config-issues-00.

The suggested "default" value in the draft is 5*MaxRtrAdvInterval.  The
"maximum" value must be larger than it.  I don't have any good technical
reason, but I propose 10*MaxRtrAdvInterval which is twice the default
value.

Thanks,
Tomoyuki

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Dec 2014 18:33:58 -0300

Hi, Tomoyuki,

Thanks so much for your feedback! Please find my comments in-line...

> draft-gont-6man-slaac-dns-config-issues-00.

Fully agree with your view. I'll keep this one in the "TODO list", and
will check what's the best way (procedurally speaking) to proceed here
-- whether to have this doc update RFC6106 or something else.

> reason, but I propose 10*MaxRtrAdvInterval which is twice the default

Makes sense.

P.S.: What do others think?

Thanks!
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tina TSOU <[email-masked]>
Date: Tue, 23 Dec 2014 03:50:14 +0000

Dear all,

I support the adoption of this document as a 6man wg document.

Below are some comments regarding to section 3:

Section 3:
   o  The entire option MUST be ignored, However, the rest of the ND
      message MAY be processed.

I do not like the "MAY be processed". Better to say "SHOULD"
or "SHOULD NOT" (whatever the wg thinks its best). The more deterministic the resulting behavior, the better.

Section 3
   o  The entire option MUST be ignored, However, the rest of the ND
      message MAY be processed.

Please rephrase as "...MUST be ignored, however, the rest.."

Section 3:
   However, when an option length attribute
   is invalid, it is not possible to parse the rest of the ND message.
   In these cases, subsequent ND options should be ignored.

Please rephrase as "...rest of the ND message, and therefore subsequent...".

P.s. Happy Holidays!

Thank you,
Tina

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Friday, December 12, 2014 8:12 PM
To: 6man WG
Cc: 6man Chairs
Subject: 6MAN WG Adoption Call: draft-gont-6man-nd-opt-validation-01

Regards,

Bob Hinden & Ole Trøan

---

From: 神明達哉 <[email-masked]>
Date: Tue, 23 Dec 2014 11:30:11 -0800

At Mon, 22 Dec 2014 18:33:58 -0300,

> -- whether to have this doc update RFC6106 or something else.
[...]
> P.S.: What do others think?

I'd suggest just removing these restrictions on the receiver side.

First off, note that RFC6106 allows a value of 0xffffffff, meaning
infinity.  So at the very least this value should be allowed (which is
currently missing in the draft).

Secondly, RFC6106 specifies the range of [MaxRtrAdvInterval,
2*MaxRtrAdvInterval]
as a SHOULD, so it's perfectly valid (albeit against the
recommendation) for a router to specify an out of range (and non-0 or
non-all-1) value.  So at the very least it's too strong to use MUST on
the receiver side.

Thirdly, given that a malicious on-link sender could use the lifetime
of 0xffffffff if they want to inject too large a lifetime, or could
use the lifetime of 0 for too short a lifetime, the range check
doesn't help much as a defense against intentional attacks.  On the
other hand, to ensure stability and robustness against operational
errors, the server side "SHOULD" would be enough (a sensible router
implementation would reject out-of-range values).  At the very least
any erroneous finite lifetime can be easily corrected via subsequent
RAs.

And, finally, there's the stability concern regarding packet loss that
triggered this discussion.

Considering all of these, it just doesn't make sense to me to
introduce any restriction on the receiver side in the first place.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 29 Dec 2014 11:02:22 -0800

At Fri, 12 Dec 2014 13:12:20 +0100,
Ole Troan <[email-masked]> wrote:

> as a working group item.

(I missed the deadline but in case it still counts) I support the
adoption of this draft as a working group item.

I reviewed and commented on a previous version of this draft, but it
has been quite some time since then, so I gave it a fresh read.  Here
are my comments on the 01 version (some of them may be a duplicate of
my previous comments; I don't remember all of them).

- Section 3

   In the spirit of "being liberal in what you receive", the first
   action is always preferred.  However, when an option length attribute
   is invalid, it is not possible to parse the rest of the ND message.
   In these cases, subsequent ND options should be ignored.

  In general, I'd be opposed to restrictions of dropping the entire ND
  message *just* because "an option length attribute is unexpected"; if
  it's invalid so that it is REALLY not possible to parse the rest of
  the ND message, then it makes sense.  An option length of 0 is one
  such case, and RFC4861 Section 4.6 already clearly states that the
  ND message should be discarded in that case.  Another kind of such
  an invalid length I can think of is too large one for the entire ND
  message.  Except for these two cases, none of the "MUST be
  discarded" rules in this draft seems to meet the condition of "not
  possible to parse the rest" to me.

  Note that this "discard the entire ND message for an unexpected
  length field" doesn't help avoid deliberate attack attempts (except
  for cases like the length of 0).  In case it's possible to parse the
  rest of the options, the intent of the attack would be to confuse
  the receiver and have it refer to bogus sequence of data (but within
  a valid range for the packet).  But such an attack can be done
  without tweaking the length field of the preceding option anyway.

  My personal suggestion is:
  - remove all of these specific rules and just revise this general
    rule in Section 3 so that it includes the above two critical cases
    (and any other if there is)
  - state that an implementation SHOULD NOT discard the entire ND
    message just because some option field does not make sense or is
    unexpected according to the current specification; as long as the
    subsequent options are parsable it SHOULD move to the next option
    (whether to handle or ignore the current option) and continue the
    process.
  - also state that an implementation SHOULD NOT assume a particular
    length of an option when it moves to the next option (whether it
    handles or ignores the current option) and SHOULD always use
    the length field of the option.  For example, an implementation
    SHOULD NOT assume the option length of 32 octets for the prefix
    information option but SHOULD refer to its length field.

- Section 4

   NS, RS, and RA messages MAY contain an SLLA Option.

  Why the RFC2119 keyword (i.e., "MAY") here?  If it's intentional,
  the choice looks quite awkward since RFC4861 uses SHOULD for some of
  these cases.

- Sections 4 and 5

   o  an address belonging to the receiving node (see Appendix A for
      rationale)

  I think I pointed this out before, but "the receiving node" is not
  really accurate and cab be misleading.  To be very accurate at the
  risk of being verbose, I suggest:

   o  an address belonging to any of the interfaces of the receiving
      node that is attached to the link where the ND message is sent
      (see Appendix A for rationale).  Note that this interface is
      usually the receiving interface of the ND message, but can be
      different if multiple interfaces are attached to the same link.
      Note also that it is possible, though unlikely, that the
      specified link-layer address happens to belong to an interface
      to a different link of the receiving node.

- Section 6

   As stated in [RFC4861] the Preferred Lifetime MUST be less than or
   equal to the Valid Lifetime.  If an incoming ND message does not pass
   this validation check, the Prefix Information Option MUST be ignored.
   However, the rest of the ND message MAY be processed.

  The preferred lifetime only matters for stateless address
  autoconfiguration (so, when the A-flag is on).  And RFC4862 already
  states the option be ignored (though without an RFC2119 keyword) if
  preferred-LT > valid-LT.  So I would see this paragraph as redundant
  (or unnecessarily strong) and my primary suggestion is to just
  remove it.  If we still really want to say something about it
  explicitly in this draft, I would suggest, e.g., something like
  this:

   As stated in [RFC4861] the Preferred Lifetime MUST be less than or
   equal to the Valid Lifetime.  If the Prefix Information Option of
   an incoming ND message whose A-flag is on, this option will be
   silently ignored as specified in [RFC4862].

- Section 10: I suggest removing this paragraph as I commented on a
  different message:

  Same for Section 11.

- Section 11: I believe I made comments on this, but to repeat them:

   The domain suffixes included in this option MUST be encoded with the
   simple encoding specified in Section 3.1 of [RFC1035].  Therefore, if
   any of the labels of a domain does not have the first two bits set to
   zero, the corresponding DNSSL option MUST be ignored.

  This paragraph doesn't make much sense to me.  The first sentence is
  just a subset of the corresponding description of RFC6106, and could
  even be ambiguous about whether the names can be compressed (RFC6106
  is very clear about it).  The second sentence awkwardly talks about
  one very specific invalid case, while there can be other kinds of
  broken representation (e.g., exceeding the 255-octet limit).  I
  suggest instead:

   [RFC6106] specifies the valid format of domain suffixes.  If a
   suffix is not validly encoded as specified, the corresponding DNSSL
   option MUST be ignored.

- Appendix A

   In Figure 10, an off-net attacker sends Router A a crafted ND
   message.

  What does an "off-net" attacker mean?  An attacker connected to
  Network 1?  If so, isn't "on-net" (or "on-link") a better term?
  If it's an attacker in somewhere else, how could it send a crafted
  ND message to (the interface to Network 1 of) Router A?

- Appendix A and B

  I think I said this before, but to repeat it: I'd like to see a
  statement of whether this is a theoretical attack scenario that
  could be annoying but its severity is unknown, or it's proved
  critical with some actual router implementations (e.g., making them
  unworkable).

Editorial nits:

- Section 3: s/ignored,/ignored./

- Section 6: s/an Prefix/a Prefix/

   ND message contains an Prefix Information Option, the Prefix

- Section 9: "ff02::0/64" should better be "ff02::/64"

   (fe80::/10) or a link-local multicast prefix (e.g., ff02::0/64).  If

--
JINMEI, Tatuya

---

From: James Woodyatt <[email-masked]>
Date: Mon, 29 Dec 2014 12:19:20 -0800

On Mon, Dec 29, 2014 at 11:02 AM, 神明達哉 <[email-masked]> wrote:

>   autoconfiguration (so, when the A-flag is on).

As RFC 4861 section 6 explains, Prefix Information options are also used
for prefix discovery.

> And RFC4862 already

The requirements in RFC 4862 apply to the Global Address Auto-configuration
function, but not clearly to the Prefix Discovery function too.

While RFC 4861 does REQUIRE that Preferred Lifetime does not exceed Valid
Lifetime, it doesn't explicitly say what to do when processing Router
Advertisement messages that violate the requirement and where L=1 and A=0.

I support keeping the current language in this draft which clarifies the
requirement that invalid Prefix Information options are also to be ignored
in processing for both prefix discovery and global address
auto-configuration purposes.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: 神明達哉 <[email-masked]>
Date: Mon, 29 Dec 2014 13:28:07 -0800

At Mon, 29 Dec 2014 12:19:20 -0800,

> As RFC 4861 section 6 explains, Prefix Information options are also used

I know that, and I don't see how it's related to the fact that the PL
lifetime only matters for SLAAC.

> function, but not clearly to the Prefix Discovery function too.

Of course, since RFC 4862 (or the preferred LT) has nothing to do
with prefix discovery.

So...

> auto-configuration purposes.

...I personally don't see the point of any clarification on
preferred-LT > valid-LT with L=1 and A=0, except for the sake of
clarification itself.  But I love clarity in general, so I wouldn't
be opposed to clarifying it either.  In that case, how to clarify it
is a different question: personally, I would rather suggest just
ignoring the preferred lifetime if A=0 since the preferred
lifetime is simply irrelevant to prefix discovery and ignoring it
seems to be closer to the usual practice of "MUST set to something on
send and MUST ignore it on receive if the value doesn't matter".
But I wouldn't be surprised if other people have different
preferences.

--
JINMEI, Tatuya

---

From: James Woodyatt <[email-masked]>
Date: Mon, 29 Dec 2014 13:48:44 -0800

Hmm. Yeah, I can see how Preferred Lifetime isn't important to Prefix
Discovery, but I don't see how it could be beneficial to make validity
check specification so complicated to permit processing invalid Prefix
Information options, i.e. when Preferred Lifetime > Valid Lifetime but
A=0.  I can see that implementations of the validity check might be a
little simpler if A=0 entails a shortcut result before loading and
comparing the Preferred and Valid Lifetime fields, but it comes at the cost
of complicating the specification of the validity check.

It would seem very odd to me if we had a specification where Preferred
Lifetime exceeding Valid Lifetime is only grounds for ignoring a Prefix
Information option in prefix discovery in the case where A=1, when the A
flag has nothing to do with prefix discovery.  Dealing with that issue
would require having two validity checks, one for prefix discovery and one
for global address auto-configuration.  Not sure that the function
abstraction there is worth the savings provided by the associated shortcut,
much less all the extra logic in the protocol requirement specification.

Seems better to just keep the current language in the draft.