Subject: AUTH48 changes to draft-ietf-6man-rfc6434-bis-09

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Dec 2018 01:20:47 -0500

Hi all,
  There are two proposed (non-editorial) changes to be made to draft-ietf-6man-rfc6434-bis-09 during the AUTH48 period and I would like to check with the WG if anyone has objections to these changes. I personally think that these are reasonable changes to make.  If I do not hear any objections by end of day December 27th 2018 (AOE), I will approve these changes and send this along the RFC publication path.

Change 1) Text change in Section 5.4. 

Old:
Neighbor Discovery SHOULD be supported. RFC 4861 states:

New:
Neighbor Discovery MUST be supported with the noted exceptions below. 
RFC 4861 states:

Change 2) New text in Section 5.4.

OLD:

<blank>

NEW:

As per RFC 6980, hosts MUST NOT employ IPv6 fragmentation for sending any of the following Neighbor Discovery and SEcure Neighbor Discovery messages: Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, Redirect, or Certification Path Solicitation.

Thanks
Suresh

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Dec 2018 15:34:00 +0900

On Thu, Dec 20, 2018 at 3:21 PM Suresh Krishnan <[email-masked]>
wrote:

>   There are two proposed (non-editorial) changes to be made to
> draft-ietf-6man-rfc6434-bis-09 during the AUTH48 period and I would like to
> check with the WG if anyone has objections to these changes. I personally
> think that these are reasonable changes to make.  If I do not hear any
> objections by end of day December 27th 2018 (AOE), I will approve these
> changes and send this along the RFC publication path.
>

Support. This clarifies that the only exceptions for ND are the ones
written immediately below. That's pretty clearly the intent of the text
already.

> ...
> As per RFC 6980, hosts MUST NOT employ IPv6 fragmentation for sending any
> of the following Neighbor Discovery and SEcure Neighbor Discovery messages:
> Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router
> Advertisement, Redirect, or Certification Path Solicitation.
>

Why? This new text text places a hard limit on the number and size of the
options that may be inserted in such a packet, and provides zero rationale.
That's not good for text in a BCP. I don't see why it needs to be included.
It's already written in RFC 6980.

---

From: <[email-masked]>
Date: Thu, 20 Dec 2018 07:24:51 +0000

Hi Suresh, 

These changes are reasonable. 

For the second one, I would add a pointer to Section 4 of 6980 which motivates the reco. 

Cheers,
Med 

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de Suresh Krishnan
> Envoyé : jeudi 20 décembre 2018 07:21
> À : 6man WG
> Cc : [email-masked]; 6man Chairs
> Objet : AUTH48 changes to draft-ietf-6man-rfc6434-bis-09
> 
> Hi all,
>   There are two proposed (non-editorial) changes to be made to draft-ietf-
> 6man-rfc6434-bis-09 during the AUTH48 period and I would like to check with
> the WG if anyone has objections to these changes. I personally think that
> these are reasonable changes to make.  If I do not hear any objections by end
> of day December 27th 2018 (AOE), I will approve these changes and send this
> along the RFC publication path.
> 
> As per RFC 6980, hosts MUST NOT employ IPv6 fragmentation for sending any of
> the following Neighbor Discovery and SEcure Neighbor Discovery messages:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Dec 2018 10:10:13 +0000

> On 20 Dec 2018, at 06:34, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Thu, Dec 20, 2018 at 3:21 PM Suresh Krishnan <[email-masked]> wrote:
> Support. This clarifies that the only exceptions for ND are the ones written immediately below. That's pretty clearly the intent of the text already.
>  
> Why? This new text text places a hard limit on the number and size of the options that may be inserted in such a packet, and provides zero rationale. That's not good for text in a BCP. I don't see why it needs to be included. It's already written in RFC 6980.

Well, RFC 6980 is standards track (not informational) and was published 5 years ago.  The principal rationale is in the abstract.

Are you aware of implementations that are still fragmenting such ND messages?

Are you suggesting we should deprecate RFC 6980. Either we believe it is good practice and encourage its adoption, if some implementations do still ignore it, or we say we no longer believe its applicable.

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Dec 2018 19:14:02 +0900

I'm saying there is no need to repeat that message in RFC6434. If we do
repeat it, we should cite 6980.

On Thu, Dec 20, 2018 at 7:10 PM Tim Chown <[email-masked]> wrote:

> > As per RFC 6980, hosts MUST NOT employ IPv6 fragmentation for sending
> any of the following Neighbor Discovery and SEcure Neighbor Discovery
> messages: Neighbor Solicitation, Neighbor Advertisement, Router
> Solicitation, Router Advertisement, Redirect, or Certification Path
> Solicitation.
> >
> > Why? This new text text places a hard limit on the number and size of
> the options that may be inserted in such a packet, and provides zero
> rationale. That's not good for text in a BCP. I don't see why it needs to
> be included. It's already written in RFC 6980.
>
> Well, RFC 6980 is standards track (not informational) and was published 5
> years ago.  The principal rationale is in the abstract.
>
> Are you suggesting we should deprecate RFC 6980. Either we believe it is
> good practice and encourage its adoption, if some implementations do still
> ignore it, or we say we no longer believe its applicable.
>
> Tim
>
>

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Dec 2018 10:22:29 +0000

> On 20 Dec 2018, at 10:14, Lorenzo Colitti <[email-masked]> wrote:
> 
> I'm saying there is no need to repeat that message in RFC6434. If we do repeat it, we should cite 6980.

OK, understood, but in 6434-bis we already say things like (for example):

" As per RFC 8200, when a node fragments an IPv6 datagram, it MUST
   include the entire IPv6 Header Chain in the first fragment."

or

"As recommended in [RFC8021], nodes MUST NOT generate atomic
   fragments"

So this is in a similar style.

Or should we prefix the text below with something like "To facilitate simple and
   effective countermeasures for Neighbor Discovery attacks...."

Or can you suggest alternative wording?

Tim

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Dec 2018 08:25:16 -0800

Suresh,

> On Dec 19, 2018, at 10:20 PM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi all,

I think we should make both changes.

Regarding the fragmentation of ND messages, RFC6980 say it applies to all nodes, not just Hosts.   This text should be consistent with that.  Might also add something like “See RFC 6980 for details and motivation”.

Thanks,
Bob

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Dec 2018 11:33:03 -0600

On Thu, Dec 20, 2018 at 10:25 AM Bob Hinden <[email-masked]> wrote:

> Regarding the fragmentation of ND messages, RFC6980 say it applies to all
> nodes, not just Hosts.   This text should be consistent with that.  Might
> also add something like “See RFC 6980 for details and motivation”.
>

+1

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Dec 2018 18:35:33 +0100

> As per RFC 6980, hosts MUST NOT employ IPv6 fragmentation for sending any of the following Neighbor Discovery and SEcure Neighbor Discovery messages: Neighbor Solicitation, Neighbor Advertisement,…

Is it intentional that this places a requirement only on senders, not on receivers?
It’s the receivers that are subject to the attacks enabled by fragmentation, so they are the ones that would need to ignore fragmented ND messages.

Grüße, Carsten

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Dec 2018 10:16:57 -0800

Carsten,

> On Dec 20, 2018, at 9:35 AM, Carsten Bormann <[email-masked]> wrote:
> 

Good point, RFC6980 describes senders and receivers.   Maybe something like:

As specified in RFC 6980, nodes MUST NOT employ IPv6 fragmentation for sending any of the following Neighbor Discovery and SEcure Neighbor Discovery messages: Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, Redirect, or Certification Path Solicitation.  Nodes MUST silently ignore any of these messages on receipt if fragmented.  See RFC 6980 for details and motivation.

Bob