Subject: Re: I-D Action: draft-ietf-6man-why64-04.txt

From: Jouni Korhonen <[email-masked]>
Date: Tue, 07 Oct 2014 11:35:21 +0300

Hi,

I am somewhat late with this document. I quick question for my 
clarification. Section 4.3.1. states that RIO is not supported e.g. for 
rather recent Linuxes. What qualifies "NOT-SUP" ? The fact that it is 
experimental and not enabled by default?

- JOuni

9/10/2014 5:55 AM, Brian E Carpenter kirjoitti:
> This version just fixes a minor reference error.
>
>      Brian
>
> On 10/09/2014 14:48, [email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>   This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
>>
>>          Title           : Analysis of the 64-bit Boundary in IPv6 Addressing
>>          Authors         : Brian Carpenter
>>                            Tim Chown
>>                            Fernando Gont
>>                            Sheng Jiang
>>                            Alexandru Petrescu
>>                            Andrew Yourtchenko
>> 	Filename        : draft-ietf-6man-why64-04.txt
>> 	Pages           : 24
>> 	Date            : 2014-09-09
>>
>> Abstract:
>>     The IPv6 unicast addressing format includes a separation between the
>>     prefix used to route packets to a subnet and the interface identifier
>>     used to specify a given interface connected to that subnet.
>>     Currently the interface identifier is defined as 64 bits long for
>>     almost every case, leaving 64 bits for the subnet prefix.  This
>>     document describes the advantages of this fixed boundary and analyses
>>     the issues that would be involved in treating it as a variable
>>     boundary.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-6man-why64/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-6man-why64-04
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-why64-04
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> 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
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 8 Oct 2014 18:46:41 +0200

Hello,

+1 to Jouni’s question.

I went through the why64 document today and also found this "NOT-SUP" clause quite surprising.

Linux has been supporting RIOs since a long while.
But not by default (net.ipv6.conf.eth0.accept_ra_rt_info_max_plen sets the maximal length for which RIOs are accepted).
According to some mailing list discusses, it is not enabled by default for security concerns and/or because of the way it could interact with VPN softwares.

- Pierre

Le 7 oct. 2014 à 10:35, Jouni Korhonen <[email-masked]> a écrit :

> 
> Hi,
> 
> I am somewhat late with this document. I quick question for my clarification. Section 4.3.1. states that RIO is not supported e.g. for rather recent Linuxes. What qualifies "NOT-SUP" ? The fact that it is experimental and not enabled by default?
> 
> - JOuni
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Oct 2014 08:49:14 +1300

Fernando - this text originally came from you, can you clarify please?
If this needs a wording change, we need to know quickly.

Regards
   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Oct 2014 11:42:42 +0900

Another reason why you might not want to set accept_ra_rt_info_max_plen in
the real wold is that doing so creates a DoS scenario where an attacker can
consume all your routing table slots by sending you tens of thousands of
RIOs.

The kernel has protections against configuring too many autoconf addresses
(defaults to max 16), but nothing against configuring too many routes.

I suppose an attacker who can mount such an attack can already send you RAs
from ulimited link-local addresses, so perhaps there's no additional risk
here?

On Thu, Oct 9, 2014 at 1:46 AM, Pierre Pfister <[email-masked]>
wrote:

> But not by default (net.ipv6.conf.eth0.accept_ra_rt_info_max_plen sets the
> maximal length for which RIOs are accepted).
> According to some mailing list discusses, it is not enabled by default for
> security concerns and/or because of the way it could interact with VPN
> softwares.
>
> - Pierre
>
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Oct 2014 10:36:08 +0200

Lorenzo,

> Another reason why you might not want to set accept_ra_rt_info_max_plen in the real wold is that doing so creates a DoS scenario where an attacker can consume all your routing table slots by sending you tens of thousands of RIOs.
> 
> The kernel has protections against configuring too many autoconf addresses (defaults to max 16), but nothing against configuring too many routes.
> 
> I suppose an attacker who can mount such an attack can already send you RAs from ulimited link-local addresses, so perhaps there's no additional risk here?

a router should only send 17 RIOs in any RA per link (RFC4191). I would hope any host implementation would have also an upper bound on the number of routers it accepts on a link. given that I don't see much of an attack here.

with regards to NOT-SUPor not, if it isn't on by default it might as well not be implemented.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Oct 2014 19:28:27 +0900

On Thu, Oct 9, 2014 at 5:36 PM, Ole Troan <[email-masked]> wrote:

> a router should only send 17 RIOs in any RA per link (RFC4191). I would
> hope any host implementation would have also an upper bound on the number
> of routers it accepts on a link. given that I don't see much of an attack
> here.
>

The router can only send 17 RIOs per packet, but it can send you 100 pps or
1000 pps of them. There's no limit on the number of routers that I can see.

> with regards to NOT-SUPor not, if it isn't on by default it might as well

It doesn't matter what the Linux default is, it matters what the default is
on products that use Linux.

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Oct 2014 12:46:28 +0200

Lorenzo,

> The router can only send 17 RIOs per packet, but it can send you 100 pps or 1000 pps of them. There's no limit on the number of routers that I can see.

RFC4191 says:
   Routers SHOULD NOT send more than 17 Route Information Options in
   Router Advertisements per link.  This arbitrary bound is meant to
   reinforce that relatively few and carefully selected routes should be
   advertised to hosts.

following that a host implementation shouldn't accept an arbitrary large number of RIOs from a single router.
if you re-read what I say above, a robust host implementation should also have a limit of the number of routers it accepts on a link. and obviously also the rate of RAs it receive.

> It doesn't matter what the Linux default is, it matters what the default is on products that use Linux.

to get back on topic. RIO isn't directly relevant to the why64 draft, so if the text if contentious I'd suggest you'd just remove the RIO column.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Oct 2014 19:52:00 +0900

On Thu, Oct 9, 2014 at 7:46 PM, Ole Troan <[email-masked]> wrote:

> if you re-read what I say above, a robust host implementation should also
> have a limit of the number of routers it accepts on a link. and obviously
> also the rate of RAs it receive.
>

Sounds like a reasonable assertion. Do you know of a robust host
implementation?

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 09 Oct 2014 14:41:34 +0300

I would be in favor of removing RIO stuff.. unless there is better 
justification for the current text. We used RIOs successfully in Linuxes 
and *BSDs already around 4-5 years ago in some projects.

- Jouni

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Oct 2014 08:04:35 +1300

> and *BSDs already around 4-5 years ago in some projects.

I don't see any justification for removing the text at this late stage.
What I do need (as document editor) is clarification from Fernando
about what this NOT-SUP actually relates to. If it means the shipped
default Linux configuration that is what the document should say.

    Brian

>>> a router should only send 17 RIOs in any RA per link (RFC4191). I
>>> would hope any host implementation would have also an upper bound on
>>> the number of routers it accepts on a link. given that I don't see
>>> much of an attack here.
>>>
>>> The router can only send 17 RIOs per packet, but it can send you 100
>>> pps or 1000 pps of them. There's no limit on the number of routers
>>> that I can see.
>>
>> RFC4191 says:
>> following that a host implementation shouldn't accept an arbitrary
>> large number of RIOs from a single router.
>> if you re-read what I say above, a robust host implementation should
>> also have a limit of the number of routers it accepts on a link. and
>> obviously also the rate of RAs it receive.
>>
>>>
>> to get back on topic. RIO isn't directly relevant to the why64 draft,
>> so if the text if contentious I'd suggest you'd just remove the RIO
>> column.
>>
>> cheers,
>> Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 09 Oct 2014 16:01:00 -0300

Hi, Brian,

> If this needs a wording change, we need to know quickly.

For Linux, it turns out that this is supported, but "disabled by default".

So I'm not sure whether we should add a new tag such as "DISABLED", or
mark the corresponding entries as "ROUTE".

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Oct 2014 08:09:54 +1300

Hey, that was quick - my mail agent received it simultaneously
with sending my message saying "please reply" ;-).

Can you send me an exact text change please? This is on the
IESG agenda for 2014-10-16 so it would be good to clear this
up immediately.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 09 Oct 2014 16:10:25 -0300

On 10/08/2014 11:42 PM, Lorenzo Colitti wrote:
> Another reason why you might not want to set accept_ra_rt_info_max_plen
> in the real wold is that doing so creates a DoS scenario where an
> attacker can consume all your routing table slots by sending you tens of
> thousands of RIOs.

I think that what you want is really a limit on the number of routing
table entries, Actually, by by setting a small "max prefix len" to
mitigate the DoS attack, RIOs become useless (you'd probably only allow
/16s or the like, which renders RIOs pretty useless).

Implmentations such as OpenBSD enforce the kind of limit that I'm
referring to.

> The kernel has protections against configuring too many autoconf
> addresses (defaults to max 16), but nothing against configuring too many
> routes.
> 
> I suppose an attacker who can mount such an attack can already send you
> RAs from ulimited link-local addresses, so perhaps there's no additional
> risk here?

Many implementations already enforce a limit on the maximum number of
routers, too.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 09 Oct 2014 16:12:20 -0300

On 10/09/2014 07:52 AM, Lorenzo Colitti wrote:
> On Thu, Oct 9, 2014 at 7:46 PM, Ole Troan <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     RFC4191 says:

OpenBSD.

Thanks,

---

From: Jouni <[email-masked]>
Date: Thu, 9 Oct 2014 22:14:47 +0300

Please recheck *BSDs support as well.. I have used RFC4191 stuff successfully on *BSDs years ago.

- Jouni

---

From: Jouni <[email-masked]>
Date: Thu, 9 Oct 2014 22:18:07 +0300

> I don't see any justification for removing the text at this late stage.

Like claiming bogus stuff?

> default Linux configuration that is what the document should say.

This would serve as "better justification" I refer to in my previous mail.

- Jouni

---

From: Fernando Gont <[email-masked]>
Date: Thu, 09 Oct 2014 20:05:54 -0300

> and *BSDs already around 4-5 years ago in some projects.

Can you advice how you got it to work?  I've just checked FreeBSD 9.2
and FreeBSD 10.0, and they don't seem to enable RIO by default, and
there doesn't seem to be a sysctl to enable it.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Oct 2014 09:07:39 +0900

> mark the corresponding entries as "ROUTE".

Why not just test again with the feature enabled? After all the purpose of
the draft is to verify what implementations do with prefix lengths, not
verify if they support certain features or not.

---

From: Pierre Pfister <[email-masked]>
Date: Fri, 10 Oct 2014 08:23:50 +0200

I did the test on a netkit environment with a kernel 3.10. It works for both smaller and larger prefixes.

You have to set sysctl net.ipv6.conf.all.accept_ra_rt_info_max_plen=128 in order to allow any prefix length.
You must as well compile the kernel with CONFIG_IPV6_ROUTER_PREF. That may have been why you didn’t get the sysctls. But I think this is by default.
At least I can see it in my very-default Ubunutus and Debians.

But you can as well just look at the code. The feature is quite simple and is located in Linux net/ipv6/ndisc.c - ndisc_router_discovery.
All code related to that is between CONFIG_IPV6_ROUTER_PREF ifdefs.

Which is defined since (at least) 2.6.25: http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/net/ipv6/ndisc.c?v=2.6.25.8

Cheers

- Pierre

Le 10 oct. 2014 à 02:07, Lorenzo Colitti <[email-masked]> a écrit :

> On Fri, Oct 10, 2014 at 4:01 AM, Fernando Gont <[email-masked]> wrote:
> Why not just test again with the feature enabled? After all the purpose of the draft is to verify what implementations do with prefix lengths, not verify if they support certain features or not.

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 Oct 2014 10:19:28 +0200

[mostly off topic warning]

Pierre,

> Which is defined since (at least) 2.6.25: http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/net/ipv6/ndisc.c?v=2.6.25.8

you meant CONFIG_IPV6_ROUTE_INFO?

any idea of the rationale for accept_ra_rt_info_max_plen?
that just doesn't seem like something that has a sensible use case.

cheers,
Ole

---

From: Pierre Pfister <[email-masked]>
Date: Fri, 10 Oct 2014 10:29:58 +0200

> you meant CONFIG_IPV6_ROUTE_INFO?

Indeed, wrong copy/paste.

> that just doesn't seem like something that has a sensible use case.

I agree.
It seems they were concerned by possible attacks. Redirecting some part of the traffic.
Of course you can redirect all the traffic with basic RAs. 
I think they saw that as an even wider open door for man-in-the-middle attacks.

Cheers,

- PIerre

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 10 Oct 2014 12:29:58 +0300

Fernando,

Linux was straight forward (enable the experimental feature, compile 
kernel, and config). If I recall that was very early 3.x kernel or even 
2.x stuff.

*BSD I have very little memory. It *might* have been that we only used 
router preferences in the host (and not RIO). rtadvd on *BSD might have 
been the thing we used RIOs..

- jouni

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Oct 2014 10:25:40 -0300

Hi, Ole,

> that just doesn't seem like something that has a sensible use case.

The use case, if any, is to prevent, say, RAs advertising very long
prefixes. For example, such a thing could be leveraged to insert
lobger-matching rules that could e.g. make traffic meant to go over a
VPN tunnel to go somewhere else in the clear. (Yes, you need to take
care of ICMPv6 Redirects, too).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Oct 2014 10:23:06 -0300

Hi, Jouni,

> been the thing we used RIOs..

That sounds like a possible case -- however, in ur case we were
assessing host support.. and *BSD doesn't seem to support RIO.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Oct 2014 10:28:12 -0300

On 10/09/2014 09:07 PM, Lorenzo Colitti wrote:
> Why not just test again with the feature enabled? After all the purpose
> of the draft is to verify what implementations do with prefix lengths,
> not verify if they support certain features or not.

That's why I said that we might just flag Linux as "ROUTE", if we don't
care about the fact that such support is disabled by default.

Thanks,