Subject: Re: I-D Action: draft-akimichi-6man-ra-prefixlen-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Oct 2021 10:33:20 +1300

Hi,

I understand what this draft tries to do, but there's a problem.

There's a fix for the problem, which is to make this a stand-alone
BCP, rather than an update to RFC4861.

Here's the problem: RFC4861 was very carefully written to make
the Interface ID length a parameter, not a constant, and the value
of that parameter is defined elsewhere - not even in the addressing
architecture, but in every separate IPv6-over-foo spec. At the moment,
that parameter is indeed set to 64 in all cases. But it cannot be
written into RFC4861; it simply doesn't belong there.

Therefore, this document (which seems like a good idea) must not
update RFC4861; it must stand alone, and should probably say:

A host implementing [RFC4861] MUST NOT accept a prefix length shorter
than (128-N) where N is the interface identifier length defined by the
IPv6 addressing architecture [RFC4291].

I would strongly support this as a BCP (here or in v6ops).

Nit: 

>    Therefore, on-link prefixes with bits shorter than 64 bits violate
>    RFC 4291.

I don't think "violate" is the correct word, because (as for fe80::/64)
we could assume zero bits to fill the gap. Suggestion:

   Therefore, on-link prefixes with bits shorter than 64 bits are
   inconsistent with RFC 4291.

Regards,
   Brian Carpenter

Regards
   Brian Carpenter

On 05-Oct-21 21:58, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Host behavior to short prefix length
>         Authors         : Akimichi Ogawa
>                           Kaname Nishizuka
>                           Yoshifumi Atarashi
>                           Akira Kanai
> 	Filename        : draft-akimichi-6man-ra-prefixlen-00.txt
> 	Pages           : 5
> 	Date            : 2021-10-05
> 
> Abstract:
>    The Prefix Information Option in the IPv6 Neighbor Discovery Router
>    Advertisement message defines an 8-bit prefix length field.  Prefix
>    List entries are created using the prefix length in the Prefix
>    Information Option.  The Conceptual Model of a Host described in RFC
>    4861[RFC4861] does not clarify behavior of a host, when a short
>    prefix length is received.  This document updates RFC 4861(if
>    approved), and clarifies that hosts SHOULD NOT accept prefix length
>    shorter than /64.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-akimichi-6man-ra-prefixlen/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-akimichi-6man-ra-prefixlen-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 5 Oct 2021 15:32:02 -0700

On Tue, Oct 5, 2021 at 2:34 PM Brian E Carpenter
<[email-masked]> wrote:

> update RFC4861;

+1. This draft seems to have a very common confusion about the
(un)relationship between on-link prefixes and prefixes to configure
addresses.  There's a draft of my own that explains it:
https://www.ietf.org/archive/id/draft-jinmei-6man-prefix-clarify-00.txt
The draft has been dead for years, but I believe the content is still
applicable.

So, in addition to not update RFC4861, I believe any reference to
RFC4291 will have to be removed.

Now, on the actual problem:

   Current implementations accept up to /4 as prefix length.  Because
   current IANA allocation of GUA is limited to 2000::/3, it would be
   very easy to mislead the whole IPv6 Internet as on-link.  Which can
   lead to a DoS attack, MITM attack, etc.

Aside from that the address allocation shouldn't have nothing to do with
the issue with too short an on-link prefix length, I see the latter
can be harmful.  Like any other threats using a rogue RA, however, I'm
not so sure if this is something we have to prevent at the protocol
level; the attacker needs to be on-link to make this attack, and can
easily also pretend to be a default router with a "High" preference, for
example.  That said, it may be prudent for a host implementation to
limit the acceptable on-link prefix length to avoid having an absurdly
short one.  In that case, I'd suggest making it configurable, and this
draft would specify a default value of the shortest acceptable prefix
length.  That default value could *happen to be* 64 (although I'd
probably consider a bit larger one to allow some operational
flexibility), but, again, that's nothing to do with the addressing
architecture (at least from a purely protocol spec point of view).

BTW, if we worry about this particular kind of attack, we'd probably
also have to worry about prefixes advertised in a route information
option whose length is very short (although the implementation status of
this option may be much poorer).  And, this exact point also indicates
this has nothing to do with the addressing architecture.

--
jinmei

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Oct 2021 12:09:21 +0200

>I would strongly support this as a BCP (here or in v6ops).

I don't understand this draft. 

The draft seems to say in Section 2 that there are implementations that
when receving a prefix with the A bit set the host will assume the
prefix to be onlink.

At least that's the only way I can parse the first paragraph. The draft
does not explictly mention whether the A-bit or the L-bit is set.

The seems to me that if hosts confuse the A-bit with the L-bit then hosts
should be fixed. The BCP is to follow the specs.

Then the drafts says that if you put something bogus in a router
advertisement, like announcing 2000::/3 as onlink, it will disrupt hosts.
We know that. If you annouce a bogus default router then hosts will also be
disrupted. 

So why should we hardcode a limit on the length of a prefix that can be
considered onlink?

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Oct 2021 14:27:45 +0200

Le 05/10/2021 à 23:33, Brian E Carpenter a écrit :
> Here's the problem: RFC4861 was very carefully written to make the 
> Interface ID length a parameter, not a constant, and the value of 
> that parameter is defined elsewhere - not even in the addressing 
> architecture, but in every separate IPv6-over-foo spec. At the 
> moment, that parameter is indeed set to 64 in all cases. But it 
> cannot be written into RFC4861; it simply doesn't belong there.
> 
> than (128-N) where N is the interface identifier length defined by
> the IPv6 addressing architecture [RFC4291].
> 
> I don't think "violate" is the correct word, because (as for 
> fe80::/64) we could assume zero bits to fill the gap. Suggestion:
> 

For my part, I think that if one forbids the shorter-than-64 plens then
there would be no reason to not forbid the longer-than-64 prefixes
too, at which point one would make it a constant (#define IPv6-PLEN 64)
and that would be it.

Rather, I would look at making this draft more open.  Making it more
open would mean to list the current specs and implementations that would
be affected by it.  For example tell that the RFC 7217 'opaque IIDs for
SLAAC' allows for both shorter-than-64 and longer-than-64.  Tell that
FreeBSD implementation allows for these shorter-or-longer-than-64 IIDs
and that linux (and freebsd) forbid it even though a linux patch exists
that allow for arbitrary lengths of prefixes in RA.  Or tell about the
RFCs with specific /127 or /128 plens like in DHCPv6 and in ptp links.

Then, tell how this proposed restriction will kill these other specs and
implementations - be open about it.

With respect to this from RFC3756:
> An attacking node can send a Router Advertisement message specifying
>  that some prefix of arbitrary [e.g. a /4, my note] length is
> on-link.
[...]
> As an example, one possible approach to limiting the damage of this 
> attack is to require advertised on-link prefixes be /64s (otherwise 
> it's easy to advertise something short like 0/0 and this attack is 
> very easy).

Hmm... 'require /64' is a possible approach.  'require /64' could be a
good EXPERIMENTAL I-D and probably a good EXPERIMENTAL RFC.  So, this
I-D could be put on an EXPERIMENTAL track, rather than BCP.

There could be other better ways to deal with the that /4 onlink in RA
attack.

Alex

> Regards, Brian Carpenter
> Regards Brian Carpenter
>> Title           : Host behavior to short prefix length Authors :
>> Akimichi Ogawa Kaname Nishizuka Yoshifumi Atarashi Akira Kanai 
>> Filename        : draft-akimichi-6man-ra-prefixlen-00.txt Pages : 5
>> Date            : 2021-10-05
>> 
>> Abstract: The Prefix Information Option in the IPv6 Neighbor 
>> Discovery Router Advertisement message defines an 8-bit prefix 
>> length field.  Prefix List entries are created using the prefix 
>> length in the Prefix Information Option.  The Conceptual Model of
>> a Host described in RFC 4861[RFC4861] does not clarify behavior of
>> a host, when a short prefix length is received.  This document 
>> updates RFC 4861(if approved), and clarifies that hosts SHOULD NOT 
>> accept prefix length shorter than /64.
>> 
>> 
Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________ I-D-Announce 
>> mailing list [email-masked] 
>> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft 
>> directories: http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>

---

From: David Farmer <[email-masked]>
Date: Wed, 6 Oct 2021 11:54:48 -0500

On Wed, Oct 6, 2021 at 7:28 AM Alexandre Petrescu <
[email-masked]> wrote:

>
> For example tell that the RFC 7217 'opaque IIDs for
> SLAAC' allows for both shorter-than-64 and longer-than-64.

I'm sorry, but that is incorrect; RFC7217 neither allows nor forbids any
length, it is length agnostic. It simply doesn't speak to what lengths are
appropriate or not. Specifying the length of an IID is not part of its
charge, that is done elsewhere.

-- 
===============================================
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: David Farmer <[email-masked]>
Date: Wed, 6 Oct 2021 13:27:24 -0500

Furthermore, this would contradict RFC5942: IPv6 Subnet Model. It is very
clear that; "The on-link determination is separate from the address
assignment.  A host can have IPv6 addresses without any related on-link
prefixes or can have on-link prefixes that are not related to any IPv6
addresses that are assigned to the host."

Calling this out as a security risk, and possibly
recommending implementations ignore crazy short prefixes is probably a
good idea. But we shouldn't modify RFC4861: SLAAC or RFC5942 per se.

However, what is the appropriate prefix length to recommend? If we
recommend /64, then if you want more than one subnet, to be treated as
on-link, you have to have a separate /64 PIOs for each subnet, this seems
unnecessarily inefficient, especially if some of those prefixes won't have
the A-flag set.

I think a reasonable comprise is to allow implementations to limit the
on-link prefixes they will accept, the limit should be configurable and the
default set to the /48 site boundary, meaning that up to a site can be
considered on-link, and if a prefix for another site (or possibly another
provider) is desired, then additional PIOs are appropriate. But I have no
problem with an additional statement that in most cases /64 on-link prefix
is operationally preferred.

I think this compromise is consistent with both the IPv6 Subnet Model and
the IPv6 Addressing Architecture.

Thanks.

On Tue, Oct 5, 2021 at 4:33 PM Brian E Carpenter <
[email-masked]> wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Oct 2021 08:52:48 +1300

Ack. But that is IMHO all either Informational (if guidelines) or BCP (if 
recommendation). Definitely not standards track and probably v6ops.

Regards
   Brian

On 07-Oct-21 07:27, David Farmer wrote:
> Furthermore, this would contradict RFC5942: IPv6 Subnet Model. It is very clear that; "The on-link determination is separate from the address assignment.  A host can have IPv6 addresses without any related on-link prefixes or can have on-link prefixes that are not related to any IPv6 addresses that are assigned to the host."
> 
> Calling this out as a security risk, and possibly recommending implementations ignore crazy short prefixes is probably a good idea. But we shouldn't modify RFC4861: SLAAC or RFC5942 per se.
> 
> However, what is the appropriate prefix length to recommend? If we recommend /64, then if you want more than one subnet, to be treated 
as on-link, you have to have a separate /64 PIOs for each subnet, this seems unnecessarily inefficient, especially if some of those prefixes won't have the A-flag set.
> 
> I think a reasonable comprise is to allow implementations to limit 
the on-link prefixes they will accept, the limit should be configurable and the default set to the /48 site boundary, meaning that up to a site can be considered on-link, and if a prefix for another site (or possibly another provider) is desired, then additional PIOs are appropriate. But I have no problem with an additional statement that in most cases /64 on-link prefix is operationally preferred.
> 
> I think this compromise is consistent with both the IPv6 Subnet Model and the IPv6 Addressing Architecture.
> 
> Thanks.
> 
> On Tue, Oct 5, 2021 at 4:33 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     On 05-Oct-21 21:58, [email-masked] <mailto:[email-masked]> wrote:
>     >
>     >         Authors        
 : Akimichi Ogawa
>     >       Pages          
 : 5
>     > https://datatracker.ietf.org/doc/draft-akimichi-6man-ra-prefixlen/ <https://datatracker.ietf.org/doc/draft-akimichi-6man-ra-prefixlen/>
>     >
>     > https://datatracker.ietf.org/doc/html/draft-akimichi-6man-ra-prefixlen-00 <https://datatracker.ietf.org/doc/html/draft-akimichi-6man-ra-prefixlen-00>
>     >
>     >
>     > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>     >
>     >
>     > [email-masked] <mailto:[email-masked]>
>     > https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
>     > Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
>     > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>     >
> 
>     [email-masked] <mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/ipv6>
> David Farmer               Email:[email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Oct 2021 10:49:19 +0200

Le 06/10/2021 à 18:54, David Farmer a écrit :
> 
> On Wed, Oct 6, 2021 at 7:28 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> 
> For example tell that the RFC 7217 'opaque IIDs for SLAAC' allows for
> both shorter-than-64 and longer-than-64.
> 
> 
> I'm sorry, but that is incorrect; RFC7217 neither allows nor forbids
> any length, it is length agnostic. It simply doesn't speak to what
> lengths are appropriate or not. Specifying the length of an IID is
> not part of its charge, that is done elsewhere.

Fair enough.  RFC7217 does not say that something is explicitely allowed.

However, let me say it differently: all these documents should work
together.  If one document explicitely disallows something that another
document doesnt disallow, the end result is that that something is
disallowed.

For example, someone might send an RA with plen 63 for a Host to
legitimately form an IID of length 65, maybe for privacy resisting to
brute force attacks, or for reasons of avoiding waste of address space.
  That would be in-line with existing RFCs like RFC7217 and with future
link-layers with IIDs of len 65.

But that situation would be disallowed by this I-D which says "hosts
SHOULD NOT accept prefix length shorter than /64".

Alex

> 
> -- =============================================== David Farmer
> Email:[email-masked] <mailto:[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: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Oct 2021 10:57:42 +0200

Le 06/10/2021 à 20:27, David Farmer a écrit :
> Furthermore, this would contradict RFC5942: IPv6 Subnet Model. It is
>  very clear that; "The on-link determination is separate from the
> address assignment.  A host can have IPv6 addresses without any
> related on-link prefixes or can have on-link prefixes that are not
> related to any IPv6 addresses that are assigned to the host."

?

Why would one send an RA with a prefix on a link if not for, among other
reasons, primarily Hosts to form addresses?

YEs, on-link determination, but still why would one try to determine who
is on-link if that someone does not have an address?  How has that
someone formed an address?  Manual config of addresses, or DHCP, or
other bizarre kinds of forming addresses are often accompanied by
similarly bizarre other ways of informing the others on-link about their
addresses, including host based routes.  They  dont use these prefixes
in RAs dedicated to onlink determination.

All in all, I dont think it is good to dissociate the on-link prefixes
from forming the addresses.

Probably few opinions are of that kind, anyways.

Alex

> 
> Calling this out as a security risk, and possibly recommending
> implementations ignore crazy short prefixes is probably a good idea.
> But we shouldn't modify RFC4861: SLAAC or RFC5942 per se.
> 
> recommend /64, then if you want more than one subnet, to be treated
> as on-link, you have to have a separate /64 PIOs for each subnet,
> this seems unnecessarily inefficient, especially if some of those
> prefixes won't have the A-flag set.
> 
> the on-link prefixes they will accept, the limit should be
> configurable and the default set to the /48 site boundary, meaning
> that up to a site can be considered on-link, and if a prefix for
> another site (or possibly another provider) is desired, then
> additional PIOs are appropriate. But I have no problem with an
> additional statement that in most cases /64 on-link prefix is
> operationally preferred.
> 
> On Tue, Oct 5, 2021 at 4:33 PM Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> Hi,
> 
> A host implementing [RFC4861] MUST NOT accept a prefix length
> shorter than (128-N) where N is the interface identifier length
> defined by the IPv6 addressing architecture [RFC4291].
> 
>> Title           : Host behavior to short prefix length Authors
>> : Akimichi Ogawa Kaname Nishizuka Yoshifumi Atarashi Akira Kanai 
>> Filename        : draft-akimichi-6man-ra-prefixlen-00.txt Pages
>> : 5 Date            : 2021-10-05
>> 
>> Discovery
> Router
> <https://datatracker.ietf.org/doc/draft-akimichi-6man-ra-prefixlen/>
>> 
<https://datatracker.ietf.org/doc/html/draft-akimichi-6man-ra-prefixlen-00>
> <ftp://ftp.ietf.org/internet-drafts/>
>> 
>> 
>> mailing list [email-masked] <mailto:[email-masked]> 
> <https://www.ietf.org/mailman/listinfo/i-d-announce>
> <http://www.ietf.org/shadow.html>
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>> 
> 
> IETF IPv6 working group mailing list [email-masked]
> <mailto:[email-masked]> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Oct 2021 11:04:52 +0200

Le 07/10/2021 à 10:49, Alexandre Petrescu a écrit :
[...]
> hosts
> SHOULD NOT accept prefix length shorter than /64"

Also, would the entire RA be dropped or only the PIO part and only under 
these onlink determination circumstances?

How can one make sure that these circumstances are precisely defined?

For example, is the L A == 1 1 such a circumstance or only the
L A == 1 0 is such a circumstance?

What if there are two PIOs, each with a different L A circumstance but a 
different prefix?

What if there are very many PIOs with very various L A circumstances and 
prefixes?

How to compare the prefixes in each PIO to make sure the algorithm of 
determining the 'correct' circumstance is consistent?

Alex

>> Telecommunication Services Office of Information Technology University 
>> of Minnesota 2218 University Ave SE        Phone: