Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

From: Pete Vickers <[email-masked]>
Date: Wed, 8 Jan 2014 16:04:02 +0100

Been lurking on this particular discussion for a while, however I think this whole DHCPv6 without RAs is getting out of hand. Irrespective of if someone has a corner case and would like to do away with their RA dependance, doesn't mean that we should create a special case for it. RAs exist and work, and are for a purpose. To use a bad theoretical example, suppose I raised a request to remove ARP requirement in my DHCPv4 deployment, and wanted instead a DHCP option to provide a/the router's MAC address. I think we'd all agree that that would be rejected and that I should just accept ARP and move on.  Likewise here, just accept that your IPv6 systems should use RAs and move on.  All the arguments I've seen around control and security should be addressed elsewhere rather than trying to hardwire the RA process.

/Pete

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 16:38:15 +0100

Le 08/01/2014 16:04, Pete Vickers a écrit :
>
> Been lurking on this particular discussion for a while, however I
> think this whole DHCPv6 without RAs is getting out of hand.
> Irrespective of if someone has a corner case and would like to do
> away with their RA dependance, doesn't mean that we should create a
> special case for it. RAs exist and work, and are for a purpose. To
> use a bad theoretical example, suppose I raised a request to remove
> ARP requirement in my DHCPv4 deployment, and wanted instead a DHCP
> option to provide a/the router's MAC address. I think we'd all agree
> that that would be rejected and that I should just accept ARP and
> move on.  Likewise here, just accept that your IPv6 systems should
> use RAs and move on.  All the arguments I've seen around control and
> security should be addressed elsewhere rather than trying to hardwire
> the RA process.

I do not discuss along DHCPv6 vs RA.  That's hard to converge.

However, discussion whether DHCP-only deployments are possible, in 
theory or otherwise, may not be that mean.  Just as we state RA-only 
deployments are the way to be we can also ack that DHCP-only deployments 
do work.

One particular enterprise does RA everywhere - congratulations to them. 
  I am seriously happy for them and would be proud to work there and 
tell everybody how great that is.

That does not mean there are not other settings where RA everywhere is 
hardly feasible.  It has to do with many technical and non technical 
criteria.

Alex

>
> /Pete _______________________________________________ v6ops mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 16:53:06 +0100

[...]
> All the arguments I've seen around control and security should be
> addressed elsewhere rather than trying to hardwire the RA process.

Addressing it elsewhere?  Where?

The lack of control and security in RA, compared to DHCP, means that 
people do not need to pre-register their laptops before connecting to an 
internal Enterprise network.  That's a security risk.

In some Enterprise settings every computer connected to that network 
needs to go to a complex pre-registration, identification, involving 
filing forms, signing by hand with pencil on paper, declaring, waiting 2 
weeks, and so on.  There are tools automating that and involving DHCP.

I think it would be easier to migrate all that from v4 to v6, rather 
than introducing new protocols with their new security risks.

Alex

---

From: joel jaeggli <[email-masked]>
Date: Wed, 08 Jan 2014 08:16:44 -0800

> internal Enterprise network.  That's a security risk.

We use this thing called 802.1x

> weeks, and so on.  There are tools automating that and involving DHCP.

Because MAC addresses and host-IDs are really well protected identifiers...

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 17:25:29 +0100

Le 08/01/2014 17:16, joel jaeggli a écrit :
>> Le 08/01/2014 16:04, Pete Vickers a écrit : [...]
>>> All the arguments I've seen around control and security should
>>> be addressed elsewhere rather than trying to hardwire the RA
>>> process.
>>
>> The lack of control and security in RA, compared to DHCP, means
>> that people do not need to pre-register their laptops before
>> connecting to an internal Enterprise network.  That's a security
>> risk.
>

Which is good, and I am happy for everyone using it.

>> In some Enterprise settings every computer connected to that
>> network needs to go to a complex pre-registration, identification,
>> involving filing forms, signing by hand with pencil on paper,
>> declaring, waiting 2 weeks, and so on.  There are tools automating
>> that and involving DHCP.
>

Well yes.

Sure, one knows how to sniff and fake one.  And sure as well one knows
how to identify someone who sniffs in the first place.  'Sniffing' to
one can be perceived as active attack by someone else.

No - not everybody trusts certificates and Certificate Authorities.
Some become CAs without caring that nobody else trusts that CA.

Some big deployers become CA in 2003, last a few years, then revert back
to pencil and paper security.

Yes - some people do have processes in place that do work well, do
afford security.

YEs - some of these need to be migrated, but careful with security.

Alex

>> I think it would be easier to migrate all that from v4 to v6,
>> rather than introducing new protocols with their new security
>> risks.
>>
>> Alex
>>
>>>
>>> /Pete _______________________________________________ v6ops
>>> mailing list [email-masked]
>> _______________________________________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>

---

From: Gert Doering <[email-masked]>
Date: Wed, 8 Jan 2014 18:28:08 +0100

Hi,

> internal Enterprise network.  That's a security risk.

You're *so* misunderstanding the issues under discussion.

First, nobody prevents doing this with DHCPv6 today.  You don't need
"DHCPv6 and no RA" for this.

Then, relying on DHCP to assure that a rogue laptop will not get an
address is fake security at best (it's trivial to sniff the network,
see what addresses are in use and just manually assign something) -
so this is actually an example of policies that do not serve what they
are claiming to do.

Registering the MAC addresses and not permitting access *to the network*
for unregistered devices is much more effective, but not strongly coupled
to "DHCP" or "no RA".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Wed, 8 Jan 2014 18:29:57 +0100

Hi,

> deployments are the way to be we can also ack that DHCP-only deployments 

*They* *do* *not* *work*, unless you add in "manual configuration" or
"other sources of configuration information".

DHCPv6-only will give hosts IPv6 addresses that they can not use for
anything.  If you add information about on-link prefixes or default
routing to that, from other sources, it's not "DHCP-only deployment".

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Wed, 8 Jan 2014 11:09:26 -0800

> one can be perceived as active attack by someone else.

I'm curious... How do you identify someone sniffing your wifi network from 20 miles
away?

I can understand how you _MIGHT_ detect the forged MAC address, but detecting
the sniffing part has me very curious.

Do you really believe you can detect someone doing a passive fiber tap in the middle
of one of your long-haul circuits? Do you really believe that you can detect someone
duplicating your traffic off to a maintenance feed on one of the DACS that the circuit
flows through?

You might be able to detect sniffing in some circumstances, but reliably detecting it
in all circumstances is a hard problem and I remain unconvinced that it is solved.

Most of the time, faking a MAC address doesn't even really require all that much
sniffing. Grab something out of one of the OUIs for Apple portable devices and you
can usually get in to a lot of places. If that doesn't work, it only takes a few seconds
to sniff one.

> Some become CAs without caring that nobody else trusts that CA.

So?

> YEs - some of these need to be migrated, but careful with security.

Any security that depends on a "trusted MAC address" or "host identifier" is
the security equivalent of a screen door.

Owen

---

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

On 09/01/2014 06:28, Gert Doering wrote:
...

> for unregistered devices is much more effective, but not strongly coupled

True. However, this will become harder if the planned ephemeral 802.11
MAC addresses become widespread, as has been suggested over on the
perpass list.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Jan 2014 12:57:22 +1100

> MAC addresses become widespread, as has been suggested over on the

Then the network needs to use 802.1x and the host needs to renegotiate
as required or the use of ephemeral 802.11 MAC addresses needs to
be disabled for that network.

Ephemeral 802.11 MAC addresses are great for when you are connecting
to a hot spot.  They don't help at all in the tightly controlled
environment that doesn't want unauthorised devices being plugged
in to succeed.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 14:19:14 +0100

> "DHCPv6 and no RA" for this.

Sorry, but I agree with you obviously there may be a misunderstanding 
somewhere.

One would not appreciate an RA to allow an arbitrary Client to configure 
an IP address.  If one did so, then there is a security risk: the Client 
is able to listen at IP level everything else in that network.  This is 
a huge risk.

In some settings, one would prefer the Client to pre-register its MAC 
address by some strongly authenticated means (strong == various speech 
and gesture only humans of a particular group are capable of).

> address is fake security at best (it's trivial to sniff the network,

If someone sniffs on an Ethernet cable then a red light is showing up 
somewhere warning there's a sniffer.

If someone pretends a MAC address of somebody else then the second 
person is notified with a popup.

> so this is actually an example of policies that do not serve what they

This _may_ be an example, and may not be.

> for unregistered devices is much more effective, but not strongly coupled

Well, DHCP does have a database of these MAC addresses, whereas RA doesnt.

Existing configuration tools are connected on DHCP part of these MAC 
addresses.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 14:20:31 +0100

> "other sources of configuration information".

Checked that.

> routing to that, from other sources, it's not "DHCP-only deployment".

Ok, it would be DHCP+ICMP+NS+NA deployments?

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 14:24:52 +0100 (CET)

On Thu, 9 Jan 2014, Alexandru Petrescu wrote:

> One would not appreciate an RA to allow an arbitrary Client to configure an 
> IP address.  If one did so, then there is a security risk: the Client is able 
> to listen at IP level everything else in that network.  This is a huge risk.

There is nothing stopping you from only using DHCPv6 IA_NA. Just set the 
A=0,M=1 flags in the RA messages, and clients won't autoconfigure 
themselves but instead just use DHCPv6 for IA_NA. You then secure this by 
means of DHCPv6 inspection and automatic installation of antispoofing 
rules.

This has *nothing* to do with if RAs is required for routing or not.

In the above solution DHCPv6 is the *only* way a client gets an IPv6 
address, and RA is the *only* way it gets a default gateway. This has been 
a perfectly valid and intended deployment model for 15 years.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tore Anderson <[email-masked]>
Date: Thu, 09 Jan 2014 14:29:04 +0100

* Alexandru Petrescu

> is able to listen at IP level everything else in that network.  This is

So set the A flag to 0 in all/any Prefix Information Options included in
the RA. Doing so ensures that the clients will not configure an IP
address based on RA, as A=0 in a PIO means "no SLAAC for this prefix".

If you also set M=1 in the RA, clients will go ask DHCPv6 for an address
instead. Problem solved?

Tore

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 14:33:57 +0100

Le 08/01/2014 20:09, Owen DeLong a écrit :
>> Sure, one knows how to sniff and fake one.  And sure as well one
>> knows how to identify someone who sniffs in the first place.
>> 'Sniffing' to one can be perceived as active attack by someone
>> else.
>>
>
> I'm curious... How do you identify someone sniffing your wifi network
> from 20 miles away?
>
> I can understand how you _MIGHT_ detect the forged MAC address, but
> detecting the sniffing part has me very curious.

Depends whether we talk WiFi or Ethernet...

But here is my speculation:

For Ethernet it's simple LED on on a port which is marked 'MUST be OFF'.

For WiFi it's more complex, but I dont really understand your question.

> Do you really believe you can detect someone doing a passive fiber
> tap in the middle of one of your long-haul circuits? Do you really
> believe that you can detect someone duplicating your traffic off to a
> maintenance feed on one of the DACS that the circuit flows through?
>
> You might be able to detect sniffing in some circumstances, but
> reliably detecting it in all circumstances is a hard problem and I
> remain unconvinced that it is solved.

Right, these things seem hard to do as put above, but on another hand I
think these may have been done.

Isn't it the same technology used by other people to find where
precisely are there bugs in the cable, why is the cable not working, how
many other people are on that cable.  Send a wavelength and measure the
response time.

> Most of the time, faking a MAC address doesn't even really require
> all that much sniffing. Grab something out of one of the OUIs for
> Apple portable devices and you can usually get in to a lot of
> places.

Well, if one does that in an Enterprise where the Policy is forbidding
Apple devices it would surely get noticed.

Also, as I said many work environments store precisely the list of MAC
addresses allowed to connect.

> If that doesn't work, it only takes a few seconds to sniff one.

Yes, but that gets noticed: popup.

>> No - not everybody trusts certificates and Certificate
>> Authorities. Some become CAs without caring that nobody else trusts
>> that CA.
>
> So?

So, would 802.1x work?  Would RA security SeND work?

>> Some big deployers become CA in 2003, last a few years, then revert
>> back to pencil and paper security.
>>
> Any security that depends on a "trusted MAC address" or "host
> identifier" is the security equivalent of a screen door.

Right.  Many use that trusted MAC address together with host identifier 
and additional human-only means to avoid 'screen door' (not sure what 
that is).

That would difficult be achieve with RA only.

Alex

>>>> _______________________________________________ v6ops mailing
>>>> list [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 22:34:46 +0900

> If you also set M=1 in the RA, clients will go ask DHCPv6 for an address

The ones that support DHCPv6, yes.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 15:27:58 +0100

Le 09/01/2014 14:29, Tore Anderson a écrit :
> * Alexandru Petrescu
>
>> One would not appreciate an RA to allow an arbitrary Client to
>> configure an IP address.  If one did so, then there is a security
>> risk: the Client is able to listen at IP level everything else in
>> that network.  This is a huge risk.
>
> So set the A flag to 0 in all/any Prefix Information Options included
> in the RA. Doing so ensures that the clients will not configure an
> IP address based on RA, as A=0 in a PIO means "no SLAAC for this
> prefix".
>
> If you also set M=1 in the RA, clients will go ask DHCPv6 for an
> address instead. Problem solved?

That part of problem seems solved.

But why should there be a PIO in the RA if nobody is allowed to use it
anyway for configuring an address?  Noise?

And still there may be a problem in the publicizing the address of the
Default Router as src in the RA.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 15:31:50 +0100

Le 09/01/2014 14:24, Mikael Abrahamsson a écrit :
>> risk: the Client is able to listen at IP level everything else in that
>> network.  This is a huge risk.
>
> themselves but instead just use DHCPv6 for IA_NA. You then secure this
> by means of DHCPv6 inspection and automatic installation of antispoofing
> rules.
>
> address, and RA is the *only* way it gets a default gateway. This has
> been a perfectly valid and intended deployment model for 15 years.

As you put it reads as only a tool for one purpose.  Sounds natural and 
good to follow.

But there's a error.

Because RA also leads to auto-configuring an address (unless A).

One would have to say:

DHCPv6 is the *only* way a client gets an IPv6 address (with exception 
A), and RA is the *only* way it gets a default gateway (with exception B).

Alex

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 15:33:14 +0100 (CET)

> anyway for configuring an address?  Noise?

RA is used for routing. The only mechanism that can configure routing is 
RA. Both DHCPv6 and RA can be used for deciding addressing policy.

RA can indicate to hosts that it should point a default-route or 
more-specific routes towards a certain router. DHCPv6 cannot do this.

> Default Router as src in the RA.

Why?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 15:34:48 +0100 (CET)

> Because RA also leads to auto-configuring an address (unless A).

I wrote A=0. What's the error?

> One would have to say:
>
> DHCPv6 is the *only* way a client gets an IPv6 address (with exception A), 
> and RA is the *only* way it gets a default gateway (with exception B).

If A=0, then DHCPv6 is the only wau to get an address, yes.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 09 Jan 2014 15:41:12 +0100

* Alexandru Petrescu

> anyway for configuring an address?  Noise?

If L=1 is set in the PIO, then the host gets to configure a on-link
route to the prefix in question.

So say you have an RA: M=1 PIO 2001:db8::/124 (A=0, L=1), you may use
DHCPv6 to configure hosts A and B to have addresses 2001:db8::A and
2001:db8::A (assuming they support DHCPv6 to begin with of course)

The PIO with L=1 tells the hosts to install a direct interface route to
2001:db8::/124 on the interface they received the RA. This means
2001:db8::A may communicate directly with 2001:db8::B without their
traffic passing through the router (they'd need use NS/NA to discover
each other's MAC address first though, not unlinke ARP in IPv4).

[Side note: A PIO with both A and L flags set to zero is meaningless and
might as well be dropped entirely. In this case 2001:db8::A and
2008:db8::B could still communicate, but traffic would pass through the
router. This is actually useful in NBMA networks, like DOCSIS. My ISP
sends me PIO-less RAs and provides me with addresses only through DHCPv6
(IA_NA & IA_PD). If I want to communicate with my neighbour, traffic
needs to first pass through my ISP's CMTS.]

> Default Router as src in the RA.

If you don't want the RA originator to appear as the next-hop of a
default route on the hosts, you simply set the Router Lifetime field to
0. The hosts could still then communicate with each other (thanks to the
L=1 PIO), but wouldn't then have any way off the link unless you give it
to them some other way (manual/static config, use of subnet-router
anycast, puppet, etc.)

Tore

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 15:48:33 +0100

Le 09/01/2014 15:33, Mikael Abrahamsson a écrit :
>> But why should there be a PIO in the RA if nobody is allowed to use
>> it anyway for configuring an address?  Noise?
>
> RA is used for routing.

Well, that's a principle put very briefly, but in details one may notice
that RA is used for other less-routingly aspects such as MTU which is a
pure local variable. (and which DHCP doesnt do either).

> The only mechanism that can configure routing is RA.

Well, as you discuss, it reads head-on with a routing protocol... Many
say that it is not that good for RA to configure routing.

Actually, if you take your statement that RA is used to configure
routing and extend it to new work at IETF, you'd realize that RA is
claimed to do routing which is actually very little of more real routing.

RA does routing without computing shortest paths, without avoiding
loops, without avoiding split horizon, without converging, without 
exchanging route databases, etc.

> Both DHCPv6 and RA can be used for deciding addressing policy.

Well, not both; it looks more as now RA can decide the addressing policy 
whereas DHCP only executes (these M/O flags).

> more-specific routes towards a certain router.

Yes it can.  But I wonder whether it knows what it does.  Or is it
somebody else that must think on its belhalf and update some policy on
it from a remote control location?  Something like what is done with
updating DHCP databases, in IPv4.

> DHCPv6 cannot do this.

Right, currently DHCPv6 can not communicate a default router or a more
specific route to the Client.  If it did, then it'd take advantage of
all the existing software tools which help it make informed decisions,
inherited from IPv4.

>> And still there may be a problem in the publicizing the address of
>>  the Default Router as src in the RA.
>
> Why?

Because there is a risk in diligently allowing maps to be built about
important routers in some area.

Just as there is a risk in allowing maps of BSSIDs and MAC addresses of
Access Points in some area and why networks are 'hidden' by not always
advertising important data.

YEs, these ids could be found by active scanning as well (WiFi Probe 
Requests, Router Solicitations, DHCPv6 Solicitations); but active 
scanning is an observable operation which can be filtered early.

And yes, you are right that the existing RA+DHCP mechanics have a sense 
and seem to follow.

Alex

---

From: Tim Chown <[email-masked]>
Date: Thu, 9 Jan 2014 14:49:19 +0000

On 9 Jan 2014, at 14:33, Mikael Abrahamsson <[email-masked]> wrote:

>> But why should there be a PIO in the RA if nobody is allowed to use it anyway for configuring an address?  Noise?
> 
> RA is used for routing. The only mechanism that can configure routing is RA. Both DHCPv6 and RA can be used for deciding addressing policy.
> 
> RA can indicate to hosts that it should point a default-route or more-specific routes towards a certain router. DHCPv6 cannot do this.

Well, RFC7078 can influence address selection which, if routing within a site is based on both src and dst (as has been demonstrated in simple homenet scenarios), can allow traffic to pass out through the preferred exit router.

Tim

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 15:50:15 +0100

Le 09/01/2014 15:34, Mikael Abrahamsson a écrit :
>>> There is nothing stopping you from only using DHCPv6 IA_NA. Just
>>> set the A=0,M=1 flags in the RA messages, and clients won't
>>> autoconfigure
>>
>> But there's a error.
>>
>> DHCPv6 is the *only* way a client gets an IPv6 address (with
>> exception A), and RA is the *only* way it gets a default gateway
>> (with exception B).
>

Right.

And what's the bit such that DHCPv6 be the only way to get routing
information?

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 15:52:44 +0100 (CET)

> And what's the bit such that DHCPv6 be the only way to get routing

I don't understand this statement/question. Please re-phrase.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 16:01:40 +0100

Le 09/01/2014 15:41, Tore Anderson a écrit :
> * Alexandru Petrescu
>
>> But why should there be a PIO in the RA if nobody is allowed to
>> use it anyway for configuring an address?  Noise?
>
> The PIO with L=1 tells the hosts to install a direct interface route
> to 2001:db8::/124 on the interface they received the RA.

Why should it be so?

The prefix length of the IPv6 address delivered by DHCPv6 should be
delivered by... DHCPv6.  With that the Client could install the
'on-link' or 'connected' route.

No?

> This means 2001:db8::A may communicate directly with 2001:db8::B
> without their traffic passing through the router (they'd need use
> NS/NA to discover each other's MAC address first though, not unlinke
> ARP in IPv4).

Right.

And this can be realized with DHCPv6 providing the prefix length, and
then Client do NS/NA.

> [Side note: A PIO with both A and L flags set to zero is meaningless
> and might as well be dropped entirely. In this case 2001:db8::A and
> 2008:db8::B could still communicate, but traffic would pass through
> the router. This is actually useful in NBMA networks, like DOCSIS.
> My ISP sends me PIO-less RAs and provides me with addresses only
> through DHCPv6 (IA_NA & IA_PD). If I want to communicate with my
> neighbour, traffic needs to first pass through my ISP's CMTS.]

I agree with you in some sense where some combination of A and L bits of
RA's PIO may make little sense.  Especially because they're so different
than IPv4. (IPv4 RAs like RFC1256).

> default route on the hosts, you simply set the Router Lifetime field
> to 0.

Yes, I agree.

But an RA without PIO and a reset Router Lifetime would make little
sense other than suggesting an attacker that is a candidate of being the
default router.  The address of the default router is in the src field
of that RA.

> The hosts could still then communicate with each other (thanks to the
> L=1 PIO),  but wouldn't then have any way off the link unless you give
> it to them some other way (manual/static config, use of subnet-router
> anycast, puppet, etc.)

Ok.

I understand you and you explain well.  The DHCP+RA mechanics do work 
for some purposes, but not for all.  As of now, they're still a manner 
to unsecurely advertise information, mandatory everywhere.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 16:05:58 +0100 (CET)

> Why should it be so?

Becase that is how it was designed.

> 'on-link' or 'connected' route.

Nope, DHCPv6 hands out /128. Addresses. Not networks, not routing. 
Addresses. By design.

> to unsecurely advertise information, mandatory everywhere.

Why are they less secure than DHCPv6?

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 16:06:42 +0100

> I don't understand this statement/question. Please re-phrase.

I meant to say it would be good to have

- a RA bit to state that DHCPv6 is the only way to get routing
   information (as there is a bit to state that DHCP is the only way to
   get an address.)

- a DHCPv6 bit to state that the Client should  use RA to
   auto-configure an address (as there is a RA bit to state to use DHCP
   to auto-configure an address).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 16:17:19 +0100

> Nope, DHCPv6 hands out /128. Addresses. Not networks, not routing.

I will not say that is wrong design, but one may imagine what I think
about it when comparing to DHCPv4.

And I'll get back wondering what to tell customer about migrating to
IPv6?  Just like IPv4 plus a few bits?  It's huge bits...

>> I understand you and you explain well.  The DHCP+RA mechanics do
>> work for some purposes, but not for all.  As of now, they're still
>> a manner to unsecurely advertise information, mandatory
>> everywhere.
>

Because if a DHCPv6 server received a hypothetical request about the
Default Router it may compare the src MAC address against of
pre-established list, and may reply 'No Such Number'.  Whereas RA
multicasts it to anyone without being asked.

And yes, there may be a question of comparing RA security (SeND) against
DHCPv6 security and we could discuss that separately if you wish.

Alex

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 9 Jan 2014 18:08:49 +0100

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Thursday, January 09, 2014 4:07 PM
> To: Mikael Abrahamsson
> Cc: [email-masked]
> Subject: Re: [v6ops] control and security of DHCP
> 
 
>    information (as there is a bit to state that DHCP is the
 
There is no routing delivered by DHCPv6 as it is by design delivering no routing information,
it's done by the RAs.

> Alex

Ales

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 9 Jan 2014 18:15:47 +0100

> Sent: Thursday, January 09, 2014 3:49 PM
> To: Mikael Abrahamsson
> Cc: [email-masked]; Pete Vickers
> Well, that's a principle put very briefly, but in details one
> may notice that RA is used for other less-routingly aspects
> such as MTU which is a pure local variable. (and which DHCP
> doesnt do either).

As MTU is usually link specific, RA/ICMPv6 seems to be a good fit.
 
> Well, as you discuss, it reads head-on with a routing
> protocol... Many say that it is not that good for RA to
> configure routing.
> 
> Actually, if you take your statement that RA is used to
> configure routing and extend it to new work at IETF, you'd
> realize that RA is claimed to do routing which is actually
> very little of more real routing.
> 
> RA does routing without computing shortest paths, without
> avoiding loops, without avoiding split horizon, without
> converging, without exchanging route databases, etc.

RA does provide the host with routing information. It is not a dynamic 
routing protocol as per your description above.

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 10:04:20 +0100

> There is no routing delivered by DHCPv6 as it is by design delivering no routing information,

Well it's good to have principles like that, but is one really sure.

Would address selection policy qualify as part or some form of some 
routing information?

Similary, would Prefix Delegation qualify as parts of routing information?

I would say yes they qualify and yes they are delivered by DHCP; and 
seem to be exceptions to the rule that DHCP design is not delivering 
routing information.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 10:09:41 +0100

> As MTU is usually link specific, RA/ICMPv6 seems to be a good fit.

Yes.  link-specific vs network-specific I suppose?

Isn't MTU part of PMTUD which is network-specific?

DHCP seems a good fit to provide MTU as well.

> routing protocol as per your description above.

Right, but routing would not work without a good dynamic routing protocol.

It would make little sense to have good RAs without being backed by a 
good dynamic routing protocol, right?  And, since other parts of this 
dynamic routing would need Prefix Delegation (which is exclusively a 
DHCP or OSPF feature, not RA), one may find that it may make little 
sense for RA to provide routing.  In some contexts where DHCP and OSPF 
already prevail.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Jan 2014 10:31:59 +0100 (CET)

> Isn't MTU part of PMTUD which is network-specific?

No, MTU is by definiteion link-specific. A network can choose to run the 
same MTU everywhere, but it's still decided on a per-link basis.

> DHCP seems a good fit to provide MTU as well.

*Sigh*. No, it doesn't. MTU is derived from settings on the router. This 
is why RA is a great fit, as the router sends the RAs and can derive the 
MTU settings from it's interface setting. In order for this to work 
decently, the DHCPv6 forwarding agent in the router would have to gain 
functionality to re-write MTU if it does forwarding.

> sense for RA to provide routing.  In some contexts where DHCP and OSPF 

DHCP configures hosts. DHCPv6-PD is an exception, since it configures a 
router. There is little else in DHCP that configures routers.

There was a long discussion on the DHC list about what DHCP configures. I 
don't know if consensus was reached. Guess that depends on who you ask as 
well...

---

From: Vízdal Aleš <[email-masked]>
Date: Fri, 10 Jan 2014 10:56:26 +0100

> From: Alexandru Petrescu
> [mailto:[email-masked]]
> Sent: Friday, January 10, 2014 10:04 AM
> To: Vízdal Aleš; Mikael Abrahamsson
> Cc: [email-masked]
> Alexandru
> >> Petrescu
> >>     information (as there is a bit to state that DHCP is
> the only way
> >> to
> >>     get an address.)
> >
> > There is no routing delivered by DHCPv6 as it is by design
> delivering
> > no routing information, it's done by the RAs.
> 
> Would address selection policy qualify as part or some form
> of some routing information?
> 
> I would say yes they qualify and yes they are delivered by
> DHCP; and seem to be exceptions to the rule that DHCP design
> is not delivering routing information.
> 
> Alex

DHCP-PD is delivering a Prefix (an IP resource), so in my eyes DHCP-PD is not providing routing.

Following your generalisation, you could say that DHCPv4 is providing an address that is installed 
into the routing table, so it is providing a routing information, so DHCPv4 is a routing protocol.

Let's stop it here. 

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 11:07:43 +0100

> DHCP-PD is delivering a Prefix (an IP resource), so in my eyes DHCP-PD is not providing routing.

Well, when one tries to build more expanded and dynamic networks with 
DHCP and RA one notices all these routing complexities and looses many 
of the hardcoded principles.

Ok.

Alex

---

From: Gert Doering <[email-masked]>
Date: Fri, 10 Jan 2014 11:14:16 +0100

Hi,

> is able to listen at IP level everything else in that network.  This is 

The client is able to listen to everything else in that network, even
if it has no IP or IPv6 address at all.  It does not even have to have
a MAC address to listen.

Please.  Some reality check.  Just a little bit.

Gert Doering
        -- NetMaster

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 11:17:04 +0100

Le 10/01/2014 10:31, Mikael Abrahamsson a écrit :
> No, MTU is by definiteion link-specific.

I know the principle yes, a link's MTU is link-specific.

But this does not forbid clients to try to figure out the MTU of an 
entire path.  PMTUD Path MTU Discovery is such a thing, works with ICMP 
messages which are not restricted to one single link.

> A network can choose to run the

YEs, except that that decision is not communicated to Clients and they 
may need it, because rarely Clients talk to others just on same link.

> functionality to re-write MTU if it does forwarding.

A-ha.

> router. There is little else in DHCP that configures routers.

One other principle that has many exceptions.

DHCPv6-PD configures routers which act as hosts as well.

> There was a long discussion on the DHC list about what DHCP configures.
> I don't know if consensus was reached. Guess that depends on who you ask
> as well...

I agree with you on that.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 11:19:07 +0100

> if it has no IP or IPv6 address at all.  It does not even have to have

YEs and no, depends on many things.

It may listed without even having a MAC address, and it will get noticed.

Also, without a MAC address it may listen but hear less than if it had a 
MAC address.

Alex

---

From: Pete Vickers <[email-masked]>
Date: Fri, 10 Jan 2014 11:20:01 +0100

After my last email, I have yet to see a reply with any valid reason [1] for not using RAs in addition to DHCPv6 for completing host configuration at a site where DHCPv6 is desired. If someone is squirreling one away, I'd love to hear it. Otherwise, I don't see the problem with deploying (existing) standards compliant solutions.

The IPv6 protocol suite is complex enough as it is today, so why make it unnecessarily more complicated by adding duplicate functionality without good (documented) reason. The recent discussions have shown that existing options (in RA and RFC defined host behaviour) seem to give more than enough flexibility to give Ops staff the tools to achieve connectivity goals.

A router is going to have a _much_ better idea of the network infrastructure's topology, availability and configuration, than a remote (DHCP) server - and is therefore a much better source of relevant network information to advise hosts (via RAs). Even in DHCPv4 it is common to provide a HSRP/VRRP IPv4 address as the default gateway, and thus essentially delegating that 'configuration option' to the router(s) not DHCP server. 

It would have been a very different history if site Ops had said "we're not moving from (e.g.) IPX to IPv4, since XYZ-IPX-specific-feature works in a different way'. We need to take a more pragmatic approach to such migrations if we're ever to actually achieve it.

[1] DHCP is realistically a (great) convience tool rather a security tool. There is little that DHCP can do that you cannot alternatively do via manual host configuration.

The withholding of a suitable IPv* address for a network that a host is already connected to, is merely security through obscurity and as such a very poor (although arguably populate) imitation.  As others have pointed out here, merely guessing a random MAC with a popular vendor's OUI could easily defeat such 'security' hurdels.

It is clearly documented from numerous sources that proper 'first layer' network security can be achieved by a blend of physical security (wired ports), and/or appropriate solutions such as 802.1x and switch/AP configuration; and then complemented where necessary via encryption & AAA etc etc etc. as per organisation's security policy.

/Pete

On 10. jan. 2014, at 10:09, Alexandru Petrescu <[email-masked]> wrote:

> It would make little sense to have good RAs without being backed by a good dynamic routing protocol, right?  And, since other parts of this dynamic routing would need Prefix Delegation (which is exclusively a DHCP or OSPF feature, not RA), one may find that it may make little sense for RA to provide routing.  In some contexts where DHCP and OSPF already prevail.
> 
> Alex
> 
>> 
>>> Alex
>> 
>> Ales
>> 
>> 
> 
>

---

From: Gert Doering <[email-masked]>
Date: Fri, 10 Jan 2014 12:19:45 +0100

Hi,

> Also, without a MAC address it may listen but hear less than if it had a 

Get a basic networking course.

Gert Doering
        -- NetMaster

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 12:39:19 +0100

> Get a basic networking course.

Hmm, is this some arrogance?

Alex

---

From: [email-masked]
Date: Fri, 10 Jan 2014 12:46:10 +0100 (CET)

> The withholding of a suitable IPv* address for a network that a host is already connected to, is merely security through obscurity and as such a very poor (although arguably populate) imitation.  A…

Some of us run BRAS boxes where a customer simply won't be able to get on
the net unless the BRAS relay agent has sent a DHCPACK to the customer.
In such configurations it is *not* merely security by obscurity.

I certainly agree that DHCP *by itself* doesn't prevent IP or MAC address
spoofing.

Steinar Haug, AS2116

---

From: Pete Vickers <[email-masked]>
Date: Fri, 10 Jan 2014 15:10:40 +0100

> I certainly agree that DHCP *by itself* doesn't prevent IP or MAC address

Sure, I agree port control that is tightly linked to specific DHCP packet dialogue could limit the pre 'authorised' access. (although rogues could potentially still listen, or even DoS your DHCP server).

However if you're relying on MAC address to verify identity, then consider that many/most ethernet devices have their MAC address declared on the outside of the box, so this appears to me to be the same as requiring users to write their non-expiring password on a post-it note on their screen, where anyone can see and duplicate it.

More relevant to the subject in hand, what is it that prevents your users from utilising RAs to discover a default gateway (in addition to address allocation via DHCPv6 ?)

/Pete

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 10 Jan 2014 15:45:01 +0000

On 10/01/2014 14:10, Pete Vickers wrote:
> More relevant to the subject in hand, what is it that prevents your
> users from utilising RAs to discover a default gateway (in addition to
> address allocation via DHCPv6 ?)

The RA model is critically weak regarding security.  In a shared tenant l2
domain, a single rogue RA packet can wipe out connectivity for an entire
network within nanoseconds.  At least in the IPv4 world where we use DHCP,
an unprotected rogue DHCP server can be detected in human time and cannot
take out an entire network with a single unsolicited packet, even if it
might do a small amount of damage before the rogue server is taken out of
operation.

With the current RA model, the only way to prevent this is to ensure that
the l2 edge is fully secured against RA leaks.  Most shared L2 domain
networking equipment does not support this at the moment (VM hypervisors
are what concern me right now, but the problem is not limited to just them).

Consequently the requirement for hosts to listen to and act on RAs means
that dynamically configured IPv6 is largely undeployable in shared tenant
configurations.

Even if RA guard were ubiquitous, the RA model will never have functional
defence in depth or damage limitation capabilities which means that it will
always be highly susceptible to operator error.  As a separate issue, we
need to stop pretending that SEND will be a cure for this problem because
apart from anything else it's completely impractical. I don't want my
routers' control planes processing thousands of pps of encrypted NS/ND for
the thousands or tens of thousands of connected hosts that they will be
handling, and that's assuming there will ever be widespread support for
SEND - which is not at all clear at this point.

I find this behaviour mode of RAs to be deeply harmful and this is the
reason I do not wish my tenant hosts to listen to RAs in the first place.
RAs may be fine for many situations, but not for this one.

Whether people like this or not, this works well with the dhcp model in
ipv4.  If the same capabilities were available in ipv6, it would be vastly
preferable to RAs from a technical point of view.

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Jan 2014 16:54:35 +0100 (CET)

> might do a small amount of damage before the rogue server is taken out of

Yet IPv4 has the same kind of problems, like gratuitous ARP or L2 
spoofing, or whatever. So unless you secure against these, you're 
screwed.

So whilst I will agree that SEND isn't a good solution, the only way to 
fix this is to actually implement L2 equipment doing L3 inspection and 
security, both for IPv4 and for IPv6. Yes this is a problem, but it's not 
a motivator to implement handing out routing via DHCPv6.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 10 Jan 2014 15:55:57 +0000

On 10/01/2014 15:54, Mikael Abrahamsson wrote:
> So whilst I will agree that SEND isn't a good solution, the only way to fix
> this is to actually implement L2 equipment doing L3 inspection and
> security, both for IPv4 and for IPv6. Yes this is a problem, but it's not a
> motivator to implement handing out routing via DHCPv6.

Then we need to politely disagree on this point.

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Jan 2014 17:13:32 +0000

Hi, I am just beginning to get the flavor for this discussion but what I am
finding lacking is a consideration for the _different link types_ for which
DHCPv6 vs RS/RA would apply. For example, AERO links are link-local only and
there is actually very little useful information that could be gotten from
an RS/RA exchange that could not just as easily be gotten from NS/NA. There,
DHCPv6-PD may be all that is needed.

Similarly, on managed network links DHCPv6 gives a central administrative
control point for coordinating all of the managed links.

So, what are the link types where we would expect to see RS/RA? Unmanaged
edge links where visiting nodes come and go at random times? Others?

Thanks - Fred
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jan 2014 12:54:30 -0500

On Jan 10, 2014, at 10:54 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Yet IPv4 has the same kind of problems, like gratuitous ARP or L2 spoofing, or whatever. So unless you secure against these, you're screwed.

Mikael, you've entirely missed Nick's point.   A gratuitous RA can have the effect he's talking about without any intentional action.   In order to take down an IPv4 network with ARP, you either have to have a device configured to proxy arp, which is easy to detect and the effects of which clear up rapidly, or else you have to have someone intentionally attacking the network, which again is easy to detect and fix.

I don't know how serious the problem Nick has described really is in practice, but it is quite clearly different than the problem you are talking about, and at least potentially does seem to have the impact that Nick ascribes to it: that it makes multi-tenant networking more expensive.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Jan 2014 19:04:29 +0100 (CET)

On Fri, 10 Jan 2014, Ted Lemon wrote:

> I don't know how serious the problem Nick has described really is in 
> practice, but it is quite clearly different than the problem you are 
> talking about, and at least potentially does seem to have the impact 
> that Nick ascribes to it: that it makes multi-tenant networking more 
> expensive.

My point is that if you're building multi tenant networks without this 
kind of protection you're screwed for both IPv4 and IPv6. IPv6 is no worse 
than IPv4 in this aspect.

http://secureenduserconnection.se/certifications/sec-access-certification/

There is a lot of stuff you need to do for both IPv4 and IPv6 in order to 
secure it. The document linked on the previous URL lists a lot of it.

Direct URL to the document:

<http://secureenduserconnection.se/wp-content/uploads/2012/02/SEC-Secure-End-user-Connection-2013-08-26.pdf>

This is SAVI stuff, but I'd still consider SAVI WG a fairly big fail since 
there is no activity now and yet when new standards are being developed, 
the SAVI WG working area isn't taken into account and its documents 
updated.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jan 2014 13:08:57 -0500

On Jan 10, 2014, at 1:04 PM, Mikael Abrahamsson <[email-masked]> wrote:
> My point is that if you're building multi tenant networks without this kind of protection you're screwed for both IPv4 and IPv6. IPv6 is no worse than IPv4 in this aspect.

I understood your point, but you are incorrect.   The operational characteristics of IPv4 and IPv6 in this context _are_ substantially different.   It's certainly true that it's better to keep tenants isolated on their own networks if you can afford to do so, and it may be that the IETF's answer is that if you can't afford to do so, tough luck. But that doesn't mean the use case Nick has presented isn't a valid one to consider.   The IETF's response, should we choose not to address it, should be "we've considered that, and don't think it's worth addressing," not "that's not a problem."

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Jan 2014 19:13:43 +0100 (CET)

On Fri, 10 Jan 2014, Ted Lemon wrote:

> I understood your point, but you are incorrect.  The operational 
> characteristics of IPv4 and IPv6 in this context _are_ substantially 
> different.  It's certainly true that it's better to keep tenants 
> isolated on their own networks if you can afford to do so, and it may be 
> that the IETF's answer is that if you can't afford to do so, tough luck. 
> But that doesn't mean the use case Nick has presented isn't a valid one 
> to consider.  The IETF's response, should we choose not to address it, 
> should be "we've considered that, and don't think it's worth 
> addressing," not "that's not a problem."

I'm considering it a huge problem in both IPv4 and IPv6 and I consider 
operators deploying multi tentant networks without these security features 
as hugely irresponsible.

However, using RA characteristics for this use-case as a reason to try to 
get default-route provisioning into DHCPv6 just doesn't make sense to me.

Yes, it can be argued IPv6 might be a little worse than IPv4, but it's 
still "rock and a hard place" and the proper response is "secure your 
access", not "make it a little less sucky by putting default route 
provisioning into DHCPv6".

---

From: Tore Anderson <[email-masked]>
Date: Fri, 10 Jan 2014 19:19:31 +0100

* Nick Hilliard

> Consequently the requirement for hosts to listen to and act on RAs
> means that dynamically configured IPv6 is largely undeployable in
> shared tenant configurations.
> 
> [...]
> 
> I find this behaviour mode of RAs to be deeply harmful and this is
> the reason I do not wish my tenant hosts to listen to RAs in the
> first place. RAs may be fine for many situations, but not for this
> one.

Your tenant hosts are in all likelihood *already* soliciting and
listening for RAs, and acting on any they receive. This means that
deploying IPv6 in your network is actually *increasing* the chance for a
rogue RA attack (deliberate or accidental) to be successful, as the
false information in the rogue RA does not have to contend with any true
information your routers would provide.

> Whether people like this or not, this works well with the dhcp model
> in ipv4.  If the same capabilities were available in ipv6, it would
> be vastly preferable to RAs from a technical point of view.

Extending DHCPv6 to have feature parity with DHCPv4 (i.e., providing a
default router option and a on-link prefix option), would not help you
at all with the problem you described above, as your tenants would still
be soliciting and listening for and acting on the (rogue) RAs. Unless if
what you are actually proposing is to also completely deprecate the
RS/RA part of ND?

Tore

---

From: Gert Doering <[email-masked]>
Date: Fri, 10 Jan 2014 19:29:48 +0100

Hi,

> what you are actually proposing is to also completely deprecate the

For Nick's use case, configuring all his systems with the equivalent
of accept_ra=0 and having address + prefix information in DHCPv6 would 
work, and be safe against rogue RAs (as in "rogue RAs are just ignored, and 
machines still get addresses and know their local neighbours").

Default-Route could be manually set to fe80::1234 which would then be
the VRRP address used in every single VLAN (something you can't do with
IPv4).  Default-Route in DHCPv6 would provide more flexibility in assigning
different default gateways for different machines, but I'm not sure *Nick*
mentioned that as a desired use case.

So I'm nearly convinced that having on-link prefix information in DHCPv6
is good (after all, the DHCPv6 server has to know this *anyway* to pick
the proper address range...).  Default-Route still reeks of "we did it 
that way in DHCPv4!"...

Gert Doering
        -- NetMaster

---

From: joel jaeggli <[email-masked]>
Date: Fri, 10 Jan 2014 10:37:56 -0800

> what you are actually proposing is to also completely deprecate the

If you goal is to use DHCPv6 exclusively you have to ignore them. which
also gets you back to the IPv4 problem of there's no basis for deciding
when to stop sending DHCP requests if you hear nothing.

---

From: Gert Doering <[email-masked]>
Date: Fri, 10 Jan 2014 19:40:59 +0100

Hi,

> when to stop sending DHCP requests if you hear nothing.

Nick's use case is fairly specific.  "If you want to live in my datacenter,
these are the rules: do not listen to RA, use DHCPv6".

This can be done.

For a generic use case "here's my mobile device, I attach it to your 
network, now I have to figure out whether this is RA, RA+DHCPv6, no-RA
with DHCPv6, or no IPv6 at all" there is madness.

Gert Doering
        -- NetMaster

---

From: Simon Perreault <[email-masked]>
Date: Fri, 10 Jan 2014 13:42:08 -0500

> when to stop sending DHCP requests if you hear nothing.

Would you consider SOL_MAX_RT [RFC7083] a sufficient solution?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Jan 2014 19:45:46 +0100 (CET)

> these are the rules: do not listen to RA, use DHCPv6".

Yes, but without intelligent inspection of RAs in the L2 network, there is 
basically no way to verify that this actually is the way things are 
configured. There are no RAs for a year, then a misconfiguration causes an 
RA to be emitted and then you find 5% of the machines in the DC haven't 
been configured to ignore RAs, and will now configure themselves by 
listening to this RA message.

This there is an absolute need to inspect traffic in the L2 network and 
thus the whole "I want a way to do this that doesn't suck when I don't 
have this L2 inspection functionality" falls flat imnho.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 10 Jan 2014 10:48:14 -0800

> these are the rules: do not listen to RA, use DHCPv6".

Right, I don't need permission to stop listening for RAs today, I can
just do it.

> with DHCPv6, or no IPv6 at all" there is madness.

One could imagine for example a dhcpv6 option to stop listening for RAs.
But that's after this process has already occurred.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 10 Jan 2014 11:07:54 -0800

On 1/10/14, 10:45 AM, Mikael Abrahamsson wrote:
> Yes, but without intelligent inspection of RAs in the L2 network, there
> is basically no way to verify that this actually is the way things are
> configured. There are no RAs for a year, then a misconfiguration causes
> an RA to be emitted and then you find 5% of the machines in the DC
> haven't been configured to ignore RAs, and will now configure themselves
> by listening to this RA message.

Today (baring deliberate action) you'll probably find 100% of them
listening for RAs, which is either great because your deployment is
going to be a lot easier when you get to the edge, a ticking bomb, or both.

Which is at least partly why this is sitting with the RFC editor right now.

https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/

That is clearly not an IPv6 deployment solution.

> have this L2 inspection functionality" falls flat imnho.

If you find it necessary to do that for IPv4 I have no doubt that you
will find it necessary for IPv6. There are other approaches, such as
limiting the diameter of the broadcast domain to a point you find
acceptable that might also be appropriate, if not always feasible.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jan 2014 14:24:41 -0500

On Jan 10, 2014, at 1:13 PM, Mikael Abrahamsson <[email-masked]> wrote:
> However, using RA characteristics for this use-case as a reason to try to get default-route provisioning into DHCPv6 just doesn't make sense to me.

This is the wrong way to think about it.   It _is_ a use case.   So you shouldn't argue that it's not a use case.   It may not be sufficient motivation to justify using DHCPv6 to deliver router information, but that's a different question.   If we keep muddling it all together into the same pot, we will never be able to come to a clear conclusion in this discussion.

> Yes, it can be argued IPv6 might be a little worse than IPv4, but it's still "rock and a hard place" and the proper response is "secure your access", not "make it a little less sucky by putting default route provisioning into DHCPv6".

You could make the case that this is the proper response, but that's what you need to do.   I think there's a fairly strong case to be made, since the privacy implications of two service providers being on the same wire are potentially dire.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jan 2014 14:26:39 -0500

On Jan 10, 2014, at 1:45 PM, Mikael Abrahamsson <[email-masked]> wrote:
> Yes, but without intelligent inspection of RAs in the L2 network, there is basically no way to verify that this actually is the way things are configured. There are no RAs for a year, then a misconfiguration causes an RA to be emitted and then you find 5% of the machines in the DC haven't been configured to ignore RAs, and will now configure themselves by listening to this RA message.

Or you could configure a host to send black-hole RAs all the time... :)

---

From: Tore Anderson <[email-masked]>
Date: Fri, 10 Jan 2014 20:32:34 +0100

* Gert Doering

> machines still get addresses and know their local neighbours").

I am making the assumption that Nick cannot change accept_ra=0 on his
tentants' hosts, because he have no control over them.

If Nick do control his tenants' hosts, nobody is stopping him from using
a DHCPv6 implementation that can signal a default route and an on-link
prefix in non-standard options. (IIRC two separate DHCPv6
implementations with this capability have been mentioned on this list
recently.) Two consenting DHCPv6 implementations can do what they want
in the privacy of their own data centre.

In a similar vein, I generally turn off RA processing on servers
configured statically via Puppet (even though tenants do not share layer
2 domains in my data centres - VLANs are cheap). The fact that the IETF
has not yet standardised IPv6 configuration using Puppet has so far not
been a hindrance to my IPv6 deployment.

Tore

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Jan 2014 20:40:10 +0100 (CET)

On Fri, 10 Jan 2014, Ted Lemon wrote:

> This is the wrong way to think about it.  It _is_ a use case.  So you 
> shouldn't argue that it's not a use case.  It may not be sufficient 
> motivation to justify using DHCPv6 to deliver router information, but 
> that's a different question.  If we keep muddling it all together into 
> the same pot, we will never be able to come to a clear conclusion in 
> this discussion.

Using enterprise L2 gear has been done commercially on a wide scale in 
Sweden since 1999 or 2000. I was myself involved in one of the first 
commercial ETTH providers here. The use-case is definitely there, that's 
how we did it initially, then in 2001-2002 we discovered there was a 
definite need for the L2 equipment to do DHCP snooping etc, because 
otherwise we ended up in the papers because neighbors could do weird 
things to each other.

Saying there is a use-case for less-sucky DHCPv6 default router handout 
because one doesn't want to do proper L2 security, doesn't make sense to 
me. Either you do it properly or you take the consequences by doing 
nothing at all.

> You could make the case that this is the proper response, but that's 
> what you need to do.  I think there's a fairly strong case to be made, 
> since the privacy implications of two service providers being on the 
> same wire are potentially dire.

Two service providers? I don't get it.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 10 Jan 2014 19:59:16 +0000

> these are the rules: do not listen to RA, use DHCPv6".

it can't be done because I have no mechanism to deliver a default gateway
without RA.  It can only be done if I ditch the idea of autoconfigured
default (or other routing) gateway and configure that statically (and also
configure the netmask statically).  But then I end up with a statically
configured network and it's an expensive mess to operate.  Even the IETF
agrees that well known addresses are a bad idea.

Also it's not "fairly specific" - it's generic to any organisation which
has a requirement for hosting clients which are not fully trusted.  E.g.
BYOD on corp networks, any shared tenant hosting, etc, although in my case
I will have limited control over the client (installed vm kernel versions,
etc).

> listening for RAs, and acting on any they receive. This means that

They aren't doing anything at the moment because I haven't yet rolled out
ipv6 to them - because I can't do so in a way which scales and is
reasonably secure from abuse.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 10 Jan 2014 20:10:30 +0000

> operators deploying multi tentant networks without these security features

It's not just stupid, it doesn't work as a business proposition.  I cannot
roll out ipv6 to shared tenant customers knowing that any one of them could
trash connectivity for everyone else.  Broken connectivity loses customers.

> Yes, it can be argued IPv6 might be a little worse than IPv4

You're stuck with a single line of defence: RA guard, and if that fails you
have nothing else.  Defence in depth is a sound engineering principal that
one does not discard lightly.

Also it makes no engineering sense to argue that just because we have a
slightly similar protocol weakness in ipv4 (gratuituous arp), we should be
happy about extending this to an additional protocol mechanism in ipv6.

Nick

---

From: Gert Doering <[email-masked]>
Date: Fri, 10 Jan 2014 21:18:07 +0100

Hi,

On Fri, Jan 10, 2014 at 07:59:16PM +0000, Nick Hilliard wrote:
> configured network and it's an expensive mess to operate.  

It would be nice if you bother to quote *all* of my mail.  The part that
you left off was "IPv6 permits you to have the same gateway address
everywhere, like fe80::1234".

If you can force your clients to never accept RAs, forcing a static
default would be about the same order of complexity, no?

> Even the IETF agrees that well known addresses are a bad idea.

That's a fairly lame argument, as those are not well known addresses
in the IETF sense, as in "it must be that way in all networks".  Your
network obviously has specific rules, "accept_ra=0" being one of them,
so why can't it have a Nick's-network-gateway rule as well?

> I will have limited control over the client (installed vm kernel versions,

No.  Especially BYOD is a completely different case, as there is just 
no way to tell joe random device to ignore RAs that might be sent by 
john doe's windows ICS...  "work without RA" is something different from
"force random devices that need to work on other networks *with* RA to
all of a sudden ignore RAs on your network".

> reasonably secure from abuse.

There will never be any way if you insist that "the IETF must ensure that
my tenant's machine will ignore RAs!" is the only solution.

Hint: by not giving your clients IPv6, you're forcing those that use
Windows to use 6to4 or Teredo unless they explicitely (manually again)
disable it.  Thanks, job well done.

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Jan 2014 20:24:54 +0000

> agrees that well known addresses are a bad idea.

If there is some way to discover both the link-local address and
link-layer address of the router, then you can configure a default
route without RA. AERO is an example link type where this is possible,
and there may be others.

Thanks - Fred

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 11 Jan 2014 01:01:24 +0100 (CET)

On Fri, 10 Jan 2014, Nick Hilliard wrote:

> You're stuck with a single line of defence: RA guard, and if that fails 
> you have nothing else.  Defence in depth is a sound engineering 
> principal that one does not discard lightly.

No, that is not the only mechanism, you can also do forced-forwarding 
towards the router, or you can do L2 separation. Actually, as IPv6 is 
today you can make this even more elegant than in IPv4, because the way 
IPv6 was designed you don't need local-proxy-arp.

> slightly similar protocol weakness in ipv4 (gratuituous arp), we should 
> be happy about extending this to an additional protocol mechanism in 
> ipv6.

Still, I don't see that changing DHCPv6 in the manner you propose actually 
solves the problem. It just changes the problem. Now you're relying on 
DHCPv6 inspection as the sole mechanism, if that fails then people can do 
whatever they want.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 11 Jan 2014 16:15:47 +0900

On Sat, Jan 11, 2014 at 2:54 AM, Ted Lemon <[email-masked]> wrote:

> spoofing, or whatever. So unless you secure against these, you're screwed.
>
> Mikael, you've entirely missed Nick's point.   A gratuitous RA can have
> the effect he's talking about without any intentional action.

... and ARP spoofing the first-hop router's MAC address can't?

Sorry to be the bearer of bad news, but Mikael is right. A malicious host
on your link WILL take down your network. You either defend against that or
you cross your fingers. And using DHCP is NOT a defense.

Ok, so ARP spoofing is not the same as a rogue RA. So here's the moral
equivalent: I set up a covert DHCP server that hands out, as next-hop
router, an on-link IP address which, by responding to ARP requests, I can
point at any on-link machine I want (including, most interestingly, either
me or the first-hop router). When doing so, I'm careful to ensure that I
hand out the proper address to every machine, such that everything
continues to work. I know what those addresses are, because I'm on-link and
ARP is a broadcast protocol.

Since I'm on-link and the "real" DHCP request has to go through 23 relays
and 4 autonomous systems (because In Enterprises, Centralized Management Is
Good), I will always win the race against the real DHCP server, so the
trusting client will use the settings I gave it. When that happens, I can
spoof a confirmation to the real server (DHCPACK or whatever it's called)
so that it doesn't know that anything is wrong.

As more and more leases are renewed, more and more trusting hosts use me as
next-hop router, but they don't notice, because I forward their packets to
the proper destination. At a key time, I start dropping all their packets,
and I am free to do so until the lease expires.

It seems to me that:

1. The effect of such an attack is no different from a rogue RA.
2. That attack is no more difficult than a rogue RA attack to pull off. (I
mean - it's more sophisticated technically, but it's not any more difficult
in terms of the barriers the operator can put in place to stop it).

>   In order to take down an IPv4 network with ARP, you either have to have
> a device configured to proxy arp, which is easy to detect and the effects
> of which clear up rapidly, or else you have to have someone intentionally
> attacking the network, which again is easy to detect and fix.
>

For configuration errors, there's RA guard. For malicious hosts, there's
real layer 2 security and VLAN segmentation. There is *nothing else*.

I know people don't do VLAN segmentation, but I'd argue that that's because
in IPv4 there is not enough address space to do it. Fortunately IPv6
provides that address space, so we won't have to waste our time doing
layering violations and gross hacks like DHCP snooping and forced
forwarding in order to defend this sort of attack - just give each tenant
their own subnet (ideally, /64) and you're done.

> talking about, and at least potentially does seem to have the impact that
> Nick ascribes to it: that it makes multi-tenant networking more expensive.

Ted - next time you support yet another of the endless use cases that
routing-in-DHCPv6 supporters put forth to justify that the Only Possible
Protocol Under The Sun To Configure Host Routing is DHCP, please do spend a
little more time thinking about "how serious the problem is".

Thanks,
Lorenzo

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 11 Jan 2014 11:09:26 +0100

Le 11/01/2014 08:15, Lorenzo Colitti a écrit :
> On Sat, Jan 11, 2014 at 2:54 AM, Ted Lemon <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Mikael, you've entirely missed Nick's point.   A gratuitous RA can
> have the effect he's talking about without any intentional action.
>
>
> Sorry to be the bearer of bad news, but Mikael is right. A malicious
> host on your link WILL take down your network. You either defend
> against that or you cross your fingers. And using DHCP is NOT a
> defense.

Maybe DHCP with pre-registered MAC addresses is not full defense but
looks maybe better than nothing.

> Ok, so ARP spoofing is not the same as a rogue RA. So here's the
> moral equivalent: I set up a covert DHCP server that hands out, as
> next-hop router, an on-link IP address which, by responding to ARP
> requests, I can point at any on-link machine I want (including, most
> interestingly, either me or the first-hop router).

The attack seems reasonable.

One possible way to initiate protection is to pre-register the MAC
address of all machines allowed to connect; this pre-registration should
be done by an out-of-band means.

This could help raise an alarm when someone connected a rogue DHCP
server using the MAC address of the legitimate server.  A popup on its
screen would say it.

> When doing so, I'm careful to ensure that I hand out the proper
> address to every machine, such that everything continues to work. I
> know what those addresses are, because I'm on-link and ARP is a
> broadcast protocol.
>
> Since I'm on-link and the "real" DHCP request has to go through 23
> relays and 4 autonomous systems (because In Enterprises, Centralized
> Management Is Good), I will always win the race against the real DHCP
> server, so the trusting client will use the settings I gave it. When
> that happens, I can spoof a confirmation to the real server (DHCPACK
> or whatever it's called) so that it doesn't know that anything is
> wrong.
>
> As more and more leases are renewed, more and more trusting hosts
> use me as next-hop router, but they don't notice, because I forward
> their packets to the proper destination. At a key time, I start
> dropping all their packets, and I am free to do so until the lease
> expires.
>
> It seems to me that:
>
> 1. The effect of such an attack is no different from a rogue RA. 2.
> That attack is no more difficult than a rogue RA attack to pull off.
> (I mean - it's more sophisticated technically, but it's not any more
> difficult in terms of the barriers the operator can put in place to
> stop it).
>
> In order to take down an IPv4 network with ARP, you either have to
> have a device configured to proxy arp, which is easy to detect and
> the effects of which clear up rapidly, or else you have to have
> someone intentionally attacking the network, which again is easy to
> detect and fix.
>
>
> For configuration errors, there's RA guard. For malicious hosts,
> there's real layer 2 security and VLAN segmentation. There is
> *nothing else*.

Well... is RA guard a panacea solution for protecting ND?

Not sure what you mean by RA guard protecting against configuration
errors, but RA guard RFC1605 is only for some particular wired
deployments (e.g. not for shared media, link must ensure always go
through router, etc.).

In addition to these particular wired environments there are the other
particular wired environments, and the other particular wired environments.

For example that would not protect Ethernet links where neighbors talk
directly at IP layer, or cellular links, or WiFi adhoc mode links, or
802.11p not-through-router links.

802.1x is also good in some environments, but not all.

Some links are so permissive in terms of who talks to who inside it, and
so strict in what they do _not_ trust outside of it, that one considers
to rather try just a little bit of security rather than keep these
networks fully disconnected from the Internet.

Alex

> I know people don't do VLAN segmentation, but I'd argue that that's
> because in IPv4 there is not enough address space to do it.
> Fortunately IPv6 provides that address space, so we won't have to
> waste our time doing layering violations and gross hacks like DHCP
> snooping and forced forwarding in order to defend this sort of
> attack - just give each tenant their own subnet (ideally, /64) and
> you're done.
>
> Ted - next time you support yet another of the endless use cases
> that routing-in-DHCPv6 supporters put forth to justify that the Only
> Possible Protocol Under The Sun To Configure Host Routing is DHCP,
> please do spend a little more time thinking about "how serious the
> problem is".
>
> Thanks, Lorenzo
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 11 Jan 2014 11:21:22 +0100

Le 10/01/2014 18:13, Templin, Fred L a écrit :
> Hi, I am just beginning to get the flavor for this discussion but
> what I am finding lacking is a consideration for the _different link
> types_ for which DHCPv6 vs RS/RA would apply. For example, AERO
> links are link-local only and there is actually very little useful
> information that could be gotten from an RS/RA exchange that could
> not just as easily be gotten from NS/NA. There, DHCPv6-PD may be all
> that is needed.
>
> Similarly, on managed network links DHCPv6 gives a central
> administrative control point for coordinating all of the managed
> links.
>
> So, what are the link types where we would expect to see RS/RA?
> Unmanaged edge links where visiting nodes come and go at random
> times? Others?

Fred,

The use of DHCP and ND would apply supposedly to the as many links as
possible.

The links I am concerned with are: cellular 1G, 2G, 3G, 4G and in the
future 5G, 869MHZ 'Alarm' IoT/M2M networks, 5.9GHz 802.11p, WiFi, wired
Ethernet, Fiber to the RSU, satellite, and more.

The additional links I have heard about here are: wired Ethernet in
Enterprise, virtual links between virtual machines ('virtual' by name
but transmitting real packets), and more.

Yes, some of these links would be termed unmanaged links where visiting
nodes come and go at random times.  On some of them it would be better
to just use RA (e.g. WiFi handovers on IPv6 hotspots), on others just
DHCP (e.g. on constrained links of machine-class devices), and yet on
others both ND and DHCP (e.g. some visitor networks in Enterprise).

Sorry if this reads too generic, but I couldnt synthesize it better than
that.

Alex

>
> Thanks - Fred [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Sat, 11 Jan 2014 08:35:54 -0500

On Jan 11, 2014, at 2:15 AM, Lorenzo Colitti <[email-masked]> wrote:
> Sorry to be the bearer of bad news, but Mikael is right. A malicious host on your link WILL take down your network. You either defend against that or you cross your fingers. And using DHCP is NOT a defense.

An RA can take down the network quickly, with a single multicast, and need not be malicious—it could simply be a mistake.   A device misconfigured to proxy ARP can do a lot of damage, but once you turn it off the damage stops in about 180 seconds (or is it 120?).

Please don't mistake my devil's advocate position here for a position advocating that we change how RA and DHCP work.   What I am trying to do is get clarity, not advocate one thing or another.   Lots of people have been arguing that they really want a DHCPv6 route option for a long time.   If it really didn't matter, they would have stopped by now, and at least it would be _different_ people arguing for it.

So, it's important to understand _why_ they are arguing for it.   It's not clear to me that there's a use case that would motivate any architectural change, but documenting the use cases that exist is worthwhile, and is something we've failed to do several times.   So when I hear people like Nick describing their use cases, I think this is constructive, and I really want to see it documented.  I do not want to see him shouted down because you are concerned that if his use cases are documented, it will motivate changes to the architecture.   That's really not how IETF process is supposed to work.

This is why I originally encouraged Andrew to work on his draft.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 11 Jan 2014 18:36:18 +0000

Lorenzo,

You're arguing that just because we have a protocol weakness in ipv4 that
it's ok to accept an additional instance of this kind of protocol weakness
in ipv6.  This is not a sensible approach to protocol engineering.

Nick

On 11/01/2014 07:15, Lorenzo Colitti wrote:
>     have a device configured to proxy arp, which is easy to detect and the
>     effects of which clear up rapidly, or else you have to have someone
>     intentionally attacking the network, which again is easy to detect and fix.
> 
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 12 Jan 2014 09:14:46 +0900

> in ipv6.  This is not a sensible approach to protocol engineering.

Actually, I think it is - because the fundamental weakness (i.e., malicious
host on L2 link) is the same, the impact is the same, and the
countermeasures are the same. Thinking it's different just because the IPv6
case uses a spoofed RA packet and the IPv4 case uses spoofed DHCP packets
is what's not sensible, I think.

In other words: you already have this problem in IPv4 with DHCP. And the
things you have to do to defend against it in IPv4 with DHCP and in IPv6
with RA are the same - either strong L2 security or link segmentation.

   - If you don't care about this problem, that's fine, but then you can't
   reasonably argue that we need routing in DHCPv6 to solve it - because
   routing in DHCPv6 can't solve it.
   - If you do care about this problem, then you will presumably put proper
   safeguards in place, and those safeguards will work for both IPv4 and IPv6,
   so you won't need routing in DHCPv6.

I do understand that you want routing in DHCPv6 for other reasons that make
sense. But I don't think this one is a reasonable justification.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 12 Jan 2014 09:50:24 +0900

On Sat, Jan 11, 2014 at 10:35 PM, Ted Lemon <[email-masked]> wrote:

> host on your link WILL take down your network. You either defend against
> that or you cross your fingers. And using DHCP is NOT a defense.
>
> An RA can take down the network quickly, with a single multicast, and need
> not be malicious—it could simply be a mistake.

RA guard is more than adequate to protect against mistakes.

>   A device misconfigured to proxy ARP can do a lot of damage, but once you
> turn it off the damage stops in about 180 seconds (or is it 120?).
>

Please read the other attack I mentioned in the same email. That's more
sophisticated than a single RA packet, but it has exactly the same effects
in DHCPv4 that a rogue RA would have.

> Please don't mistake my devil's advocate position here for a position
> advocating that we change how RA and DHCP work.   What I am trying to do is
> get clarity, not advocate one thing or another.   Lots of people have been
> arguing that they really want a DHCPv6 route option for a long time.   If
> it really didn't matter, they would have stopped by now, and at least it
> would be _different_ people arguing for it.
>

Ok, but if you want clarity, then please take the first step of analyzing
and understanding the problem yourself (you said yourself that you weren't
sure about it) before playing devil's advocate? Otherwise you're not
creating clarity, you're creating confusion.

> So, it's important to understand _why_ they are arguing for it.   It's not
> clear to me that there's a use case that would motivate any architectural
> change, but documenting the use cases that exist is worthwhile, and is
> something we've failed to do several times.

That's right - because many of the use cases that have been proposed look
reasonable on the surface, like this one, but then don't turn out to be
real.

I think the majority of the reason that people argue for routing in DHCPv6
is that they want their IPv6 designs to look like their IPv4 designs. There
are a couple of other reasons that do make sense, but they are minor, and I
think they can be fixed in other IPv6 protocols. So what happens is that
the opponents of routing in DHCPv6 ask "We don't think this is a good idea.
Do you have use cases that require it?". Then, a bunch of use cases are
documented, but unfortunately, since none of the use cases are the actual
reason ("we want IPv6 provisioning to look like IPv4"), most of them are
not convincing.

We've been through this before - if you remember, the use cases in the
latest routing-in-dhcp draft were a) written after the rest of the draft
(which is already a bit strange - in general you'd expect to document the
solution after the problem, right?), and b) determined by the WG to be
mostly bogus and thrown out.

Another recent example is
http://www.ietf.org/mail-archive/web/v6ops/current/msg18372.html . The
assertion was "we need routing in DHCPv6, and if the IETF doesn't give it
to us, we will pay for it and make it happen anyway". That seems well and
good, but the actual use case is not actually convincing. The IPv4 design
is based on static sharding hosts to four IPv4 default gateways. If you
think about it for a bit, you'll realize that four RAs and ECMP would not
only do the job, but would actually be a much better design. That fact
didn't stop this scenario from being cited as a use case.

  So when I hear people like Nick describing their use cases, I think this
> is constructive, and I really want to see it documented.  I do not want to
> see him shouted down because you are concerned that if his use cases are
> documented, it will motivate changes to the architecture.   That's really
> not how IETF process is supposed to work.
>

I'm not shouting down Nick - in fact, I replied to you, not to him. I do
think we should ensure we as a community don't decide to put routing into
DHCPv6 based on weak or invalid use cases, and I would hope that you agree
with that and will help me with it.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 11 Jan 2014 17:36:47 -0800 (PST)

>________________________________
> From: Lorenzo Colitti <[email-masked]>
>To: Nick Hilliard <[email-masked]> 
>Cc: "[email-masked] WG" <[email-masked]> 
>Sent: Sunday, 12 January 2014 11:14 AM
>Actually, I think it is - because the fundamental weakness (i.e., malicious host on L2 link) is the same, the impact is the same, and the countermeasures are the same. Thinking it's different just because the IPv6 case uses a spoofed RA packet and the IPv4 case uses spoofed DHCP packets is what's not sensible, I think.
>

So recently I've been thinking about this issue more broadly. I haven't fully thought through all the topics and content, however the title I've come up with is:

'Are Broadcast Multi-Access Subnetworks becoming "Considered Harmful"'?

BMAs, such as Ethernets, do and have provided a number of advantages:

(1) the boundary of the BMA subnetwork has been used as the boundary of an IPv4/IPv6 prefix. As a IPv4/IPv6 prefix summarises a range of addresses, that is one of the things that has allowed the routing system to scale.

(2) they've also corresponded to or been made to correspond to security domains, using e.g, VLANs. The IPv4/IPv6 prefix has then been used as a security policy tool, grouping the hosts together, to grant group rather than individual access to other resources.

(3) they could provide direct link-layer unicast, broadcast or multicast access to all other nodes (i.e., peer-to-peer or full-mesh connectivity), such as a locally attached server, reducing the costly to forward layer 3 traffic.

I think (2) is starting to be false. It assumes that all hosts can equally be trusted to not disrupt others, by either attacking them directly (via spoofing e.g., RAs, or via traffic DoS to an individual node), or by abusing the shared transmission resource the BMA provides, impacting all hosts. For this to be always and continue to be true, the trust level of each host must not change, and for it to not change it needs to be continuously operated by a trusted party and attached to the same and single BMA subnet.

I think mobility of hosts (i.e., laptops) has made that false, because something as simple as the host being attached to a different network with a different administration (e.g., a home or hotel network) may mean that the host now should not be trusted. BYOD is a more extreme case - the BMA subnetwork operator will have less or no opportunity for control over the hosts.

I think (3) has also become mostly false. Servers are grouped to together on server subnets, with the clients being on their own subnets, 1 or more layer 3 hops away. "Cloud computing" is the most extreme case of this. There is very little direct node-to-node traffic, other than traffic to operate the BMA subnetwork itself. Application traffic is mostly to or from off-link destinations or sources.

The only advantage that we still get from BMA subnetworks is being able to group hosts' layer 3 addresses together as a single prefix and then using that to scale the routing system. That is still a useful property because it avoids host routing or per-host prefix routing.

Measures such as RA guard or DHCP guard attempt to address the issue of lack of host trust, however they struggle because they're layer 2 devices attempting to perform layer 3 or higher layer analysis.

So why not properly isolate the hosts at layer 2, removing the implicit trust they have, at the cost of universal direct peer-to-peer transmission that is rarely used? Move to a hub-and-spoke forwarding model, such that they always have to go through a layer 3 intermediary that is a security policy enforcement point to reach any other host, even those within the same IPv4/IPv6 prefix, while still preserving the ability to group hosts within a single IPv4/IPv6 prefix for the benefit of scaling the routing system? Preserve broadcast/multicast to some/all hosts capability only for the trusted layer 3 intermediary.

This is certainly not a new idea - it is the "Private VLANs" or Broadband forum N:1 model (and might go by other names). However, my thoughts are that it needs to become far more common, and perhaps the default. There might be some open issues such as multicast (is it legal for a router to forward multicast back out the interface it received them from, assuming they're ok to forward, and how would a host deal with receiving it's own multicasts if the router simplistically forwards them back to all hosts, including the hosts that sent them).

I think this fundamentally means start working from an assumption that all hosts are untrusted, rather than assuming that the majority are trusted, and then putting in place less than completely effective partial measures to deal with the assumed occasional attachment of unstrusted hosts.

Regards,
Mark.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 12 Jan 2014 14:38:39 +0000

> 'Are Broadcast Multi-Access Subnetworks becoming "Considered Harmful"'?

They're probably the worst possible way of handling multiple access
networks, with the exception of all the others.

And if anyone mentions ATM, I'm totally claiming godwin.

Nick

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 13 Jan 2014 01:20:27 -0800 (PST)

----- Original Message -----
> From: Nick Hilliard <[email-masked]>
> To: Mark ZZZ Smith <[email-masked]>; Lorenzo Colitti <[email-masked]>
> Sent: Monday, 13 January 2014 1:38 AM

I think either I'm confused by what you're saying, or your confused by what I'm saying.

I'm using the term BMA to be the opposite of NBMA, and using it to be a more general description of nothing more than standard Ethernet, Wifi, Token ring etc., links i.e. a single layer 2 link or segment that supports more than two nodes ("multi-access"), allowing a single IPv4/IPv6 prefix to be used for all nodes, where any of the nodes can equally transmit or receive unicast, multicast or broadcast traffic to any, some or all of the others ("broadcast").

The fundamental capability of these links that facilitates things such as ARP spoofing, rogue DHCPv4 or DHCPv6 servers, or rogue RAs, is the ability for any node to be able to send anything to any other node without restriction. This capability may have been useful when all the attached nodes were trusted to behave, usually meaning they were operated by the same party, were always attached to the same link, meaning that they couldn't "go away" and then "bring back" malicious software, and the majority of traffic stayed within the link.

Now that we have laptops and BYOD, and the majority of traffic is to or from off-link destinations and sources, I think it would be better to move to a default hub-and-spoke forwarding model within the link, inserting an router or smarter device between each host and every other destination, including those attached to the same link/same IPv4/IPv6 prefix. The router or smarter device can then ensure that any of the attacks that rely on anything to any node within the link are suppressed/prevented.

This forwarding model may not be useful for a server farm subnet, because they're usually operated by the same party and therefore equally trustworthy. In those cases the default could be switched off, restoring anything to any node forwarding within the link.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Jan 2014 16:22:53 +0000

Alex,

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Saturday, January 11, 2014 2:21 AM
> To: [email-masked]
> Subject: Re: [v6ops] link types for both RA and DHCP 'was: control and security of DHCP)
> 

I think we are seeing it the same way. Thanks for confirming.

Fred

---

From: Ray Hunter <[email-masked]>
Date: Tue, 14 Jan 2014 08:30:28 +0100

> And if anyone mentions ATM, I'm totally claiming godwin.

Would the combination: IPv6/64 + L2 PVLAN + DHCPv6 setting the address  
+ DHCPv6 setting default router + HSRPv6 + input ACLs, provide you a 
solution to your requirements in a multi-tenant environment?
[Yes I know DHCPv6 setting default router does not yet exist in the 
world of IETF.]

Why would that be better than IPv6/64 + L2 PVLAN + RA + RA Router 
preference (4941) + DHCPv6 setting the address ?

If anything at all were possible, would your preferred combination for a 
bullet proof and predictable solution not be: prefix length >> 64 + 
PVLAN + DHCPv6 + DHCPv6 setting default router + HSRPv6 ?
[Yes I know prefix length >> 64 is heresy in IETF]

Then you'd have path equivalence and functional equivalence with IPv4 to 
ease operations and debugging.
Especially when stuff starts flapping, I suspect it's going to be a 
right royal pain to debug otherwise.

-- 
Regards,
RayH

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 14 Jan 2014 17:21:24 +0000

On 14/01/2014 07:30, Ray Hunter wrote:
> Would the combination: IPv6/64 + L2 PVLAN + DHCPv6 setting the address  +

private vlans are troublesome, to say the least.  In a virtualised
environment, you need multi-switch support for specific types of pvlans.
This places vendor restrictions on the types of kit you need to deploy.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Jan 2014 09:35:38 -0800

> This places vendor restrictions on the types of kit you need to deploy.

VLAN tagging is an IEEE standard.  It works on my cheap D-link switch at home, and I am using it there to isolate VLANs.   TRILL is another standard that supports VLAN tagging in precisely the sort of virtualized environment you are talking about, and that several vendors claim to support.   I'm pretty sure there's another IEEE standard that does something similar to what TRILL does, but I can't remember the number off the top of my head.   So is the missing piece that leads you to say what you are saying above? Is it that switches supporting TRILL and/or the IEEE mechanism are too expensive?

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 14 Jan 2014 17:45:35 +0000

On 14/01/2014 17:35, Ted Lemon wrote:
> VLAN tagging is an IEEE standard.

vlan tagging is something else.  Private vlans are vlans with vendor
specific internal segmentation so that some hosts cannot talk to other
hosts, even though they nominally inhabit the same vlan.  This is not
standardised in any meaningful way that I'm aware of and each vendor takes
their own approach per type of kit that they sell.  They have interesting
features which make them appropriate for some but not all shared tenancy
models.  Cisco documented some of their approach in rfc5517.

Nick

---

From: Ray Hunter <[email-masked]>
Date: Tue, 14 Jan 2014 19:11:17 +0100

> Nick Hilliard <mailto:[email-masked]>
> 14 January 2014 18:21
>
> ------------------------------------------------------------------------
Yes.

I've read posts from a number of DC operators who have expressly chosen 
for PVLANs compared to deploying dedicated L3 ports per server/ customer 
in multi-tenant environments, driven by a desire to save on very scarce 
public IPv4 addresses.

That of course will likely bring problems migrating to IPv6 in the 
future e.g. DAD is probably not going to be able to detect duplicate 
addresses via multicast.

Hence my suggestion of prefix length >> 64 + PVLAN + DHCPv6 + DHCPv6 
setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 setup.

It would also mean that any failovers are likely to be very similar for 
both IPv4 and IPv6 paths, and that HSRPv6//VRRPv3 generally has more 
features (track/ preempt/ MD5 authentication) which RA clearly doesn't 
have (yet), which I see as clear operational advantages. My opinion is 
that combination is a pretty valid use case for transitioning a 
multi-tenant IPv4 environment to IPv6 using dual stack, and which 
requires the additional functionality you want. Otherwise people running 
IPv4 PVLANs are going to get painted into a corner.

So what security are you suggesting to deploy to ensure that your set up 
remains sufficiently isolated between customers, even though they share 
a L2 LAN?

I'm not saying necessarily that RA should be the only game in town, but 
it is there today. And we all know how hard it is to prevent attacks by 
on-link attackers (not just RA).

-- 
Regards,
RayH

---

From: Owen DeLong <[email-masked]>
Date: Tue, 14 Jan 2014 10:17:13 -0800

On Jan 14, 2014, at 10:11 , Ray Hunter <[email-masked]> wrote:

> I've read posts from a number of DC operators who have expressly chosen for PVLANs compared to deploying dedicated L3 ports per server/ customer in multi-tenant environments, driven by a desire to save on very scarce public IPv4 addresses.

Which might make sense when the customers are on separate hardware.

When the customers are separate virtuals on the same hardware, PVLANs become a bit less useful, though at that point, dedicated L3 ports in the virtual switch on the host become much more feasible, though you still have the network addressing cost issue if you're tied to IPv4.

> That of course will likely bring problems migrating to IPv6 in the future e.g. DAD is probably not going to be able to detect duplicate addresses via multicast.

Depends on how the PVLANs treat link-scoped IPv6 multicast.

> Hence my suggestion of prefix length >> 64 + PVLAN + DHCPv6 + DHCPv6 setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 setup.

Not sure how that really helps. Why is a longer prefix length allegedly useful in this context?

Owen

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 14 Jan 2014 18:38:11 +0000

On 14/01/2014 18:11, Ray Hunter wrote:
> remains sufficiently isolated between customers, even though they share a
> L2 LAN?

Right now?  I have nothing.  I can't deploy ipv6 without holes large enough
to drive trucks through.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Jan 2014 03:52:01 +0900

> Right now?  I have nothing.  I can't deploy ipv6 without holes large enough

You can't give every customer their own /64?

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 14 Jan 2014 18:57:49 +0000

> You can't give every customer their own /64? 

Not without setting up vrrp per customer.  Doesn't scale.

Nick

---

From: Ray Hunter <[email-masked]>
Date: Tue, 14 Jan 2014 20:23:39 +0100

> Owen DeLong <mailto:[email-masked]>
> 14 January 2014 19:17
> On Jan 14, 2014, at 10:11 , Ray Hunter<[email-masked]>  wrote:
>
>>> Nick Hilliard<mailto:[email-masked]>
>>> 14 January 2014 18:21
>>>
Agreed. But if you can emulate a L2 LAN, or a L3 router, you can 
presumably also emulate a PVLAN.
> When the customers are separate virtuals on the same hardware, PVLANs become a bit less useful, though at that point, dedicated L3 ports in the virtual switch on the host become much more feasible,…
Right..
> Depends on how the PVLANs treat link-scoped IPv6 multicast.
Yes. There's no standard AFAIK.
>
>> Hence my suggestion of prefix length>>  64 + PVLAN + DHCPv6 + DHCPv6 setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 setup.
>
The context of this thread was a request for DHCPv6 to be able to set 
the default router, and avoid using RA.
That's an interesting topic.

I'm happy to continue the discussion about prefix length in detail, but 
shall we do that another time?

Is it sufficient for now to say that in a virtual environment, I think 
it's even more important to contain resource depletion problems and 
potential cross-contamination between environments? The memory used to 
contain e.g. an ND table on one virtual LAN switch or router is almost 
certainly allocated from a shared pool that may not be well protected 
from overflowing. And it's going to be very easy to fill up the TCP 
session tables in e.g. machine firewalls using ip6tables, if a single 
rogue source on the local DC LAN can spoof source addresses from the 
equivalent of an entire continent today.

-- 
Regards,
RayH

---

From: Owen DeLong <[email-masked]>
Date: Tue, 14 Jan 2014 11:50:13 -0800

On Jan 14, 2014, at 11:23 , Ray Hunter <[email-masked]> wrote:

> Agreed. But if you can emulate a L2 LAN, or a L3 router, you can presumably also emulate a PVLAN.

That doesn't necessarily follow, actually. At least in Linux, to the best of my knowledge, it's easy to set up multiple bridge groups, route between them and connect your virtual hosts accordingly. I don't know of any way to set up PVLAN emulation.

OTOH, I've always regarded PVLAN as a really horrible hackish technique for IPv4 address conservation where segmentation would be the preferred solution, so I can't imagine preferring a PVLAN solution when a VLAN solution is available unless I'm stuck in IPv4 land and short on addresses.

> Yes. There's no standard AFAIK.

There are no standards for PVLANs at all to the best of my knowledge. I suspect each vendor has a subtly different implementation and definition of the term to begin with. They're simply a terrible terrible hack that makes sense only in the context of extreme address shortage.

> The context of this thread was a request for DHCPv6 to be able to set the default router, and avoid using RA.

Still not understanding how the longer prefix helps with that.

> 
> I'm happy to continue the discussion about prefix length in detail, but shall we do that another time?
> 
> Is it sufficient for now to say that in a virtual environment, I think it's even more important to contain resource depletion problems and potential cross-contamination between environments? The memory used to contain e.g. an ND table on one virtual LAN switch or router is almost certainly allocated from a shared pool that may not be well protected from overflowing. And it's going to be very easy to fill up the TCP session tables in e.g. machine firewalls using ip6tables, if a single rogue source on the local DC LAN can spoof source addresses from the equivalent of an entire continent today.

I still don't see the cost benefit ratio of such attacks being such that they are all that likely to occur. There are easy enough ways to commit such attacks in IPv4, yet they remain quite rare. I don't see any reason they would increase in IPv6. They are high risk, low reward types of attacks.

Owen

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 14 Jan 2014 15:26:34 -0800 (PST)

----- Original Message -----
> From: Ray Hunter <[email-masked]>
> Sent: Wednesday, 15 January 2014 5:11 AM

Just an FYI,

Duplicate Address Detection Proxy
http://tools.ietf.org/html/rfc6957

My perspective on private VLANs etc. type problem has come from experience in the residential broadband environment with BYO CPE. Not only can't you control the type of CPE that is purchased, you can't assume that the people who operate them are capable of even the most basic security administration. It is a completely untrusted environment, and therefore I think solutions that work in that environment are also going to be quite effective in DC or enterprise environments.

These sorts of spoofing etc. problems are solved by per-subscriber PPPoE sessions, per subscriber single or double VLAN tags, or the N:1 / "private VLAN" model. All of them are isolating subscribers/CPE/hosts, however from a routing perspective the last one is the most scalable, because multiple subscribers/CPE/hosts are collected together within a single subnet (obviously we get use things such as routing aggregation to scale further, however there can still can be value in reducing FIB entries/PPPoE/QinQ session entries on the BRAS itself.)

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 14 Jan 2014 15:30:41 -0800 (PST)

> From: Owen DeLong <[email-masked]>
>To: Ray Hunter <[email-masked]> 
>Sent: Wednesday, 15 January 2014 6:50 AM

TR-101 from the Broadband Forum would be close to a standard.

---

From: Tim Chown <[email-masked]>
Date: Wed, 15 Jan 2014 12:08:49 +0000

> You can't give every customer their own /64? 

As a slight aside, we found that at certain vendors charge rather more for images with L3 functionality than for L2 functionality, so it costs more in real £££ to put /64 per interface.  So even if the device is capable of doing it, it's frustrating that there's a tiered pricing structure.  I'd rather the vendor recognised the potential change in IPv6 usage here and had price parity (on the lower price!).

Tim

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 15 Jan 2014 15:31:44 +0000

Hi, a /64 per customer (or maybe even a /56 or shorter) is what AERO expects.

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Wednesday, January 15, 2014 4:09 AM
To: Lorenzo Colitti
Cc: Ray Hunter; [email-masked] WG
Subject: Re: [v6ops] control and security of DHCP

On 14 Jan 2014, at 18:52, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

Tim

---

From: Owen DeLong <[email-masked]>
Date: Wed, 15 Jan 2014 11:08:40 -0800

> As a slight aside, we found that at certain vendors charge rather more for images with L3 functionality than for L2 functionality, so it costs more in real £££ to put /64 per interface.  So even if…

There certainly are vendors who do, so it seems to me that this is a valid vendor selection criteria.

Owen