Subject: RE: New draft-vasilenko-6man-nd-mitm-protection-00.txt

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 1 Oct 2020 09:26:49 +0000

Hi Fernando,
Thanks for my education - I did know about the challenge resolved in RFC 7113 (EH helps to bypass RA-Guard).

But anyway, RA-shield, RA-Guard, even with RFC 7113 extensions could be classified as simple
Compare to SAVI.

It could be that some vendors have not implemented RA-Guard properly. But standards do show the way.

There is no way shown for rogue-NA in pure SLAAC or hybrid SLAAC/DHCP environment.
Hence, this draft still has value.

Ed/
> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: 30 сентября 2020 г. 22:26
> To: Vasilenko Eduard <[email-masked]>; Philip Homburg <pch-
> [email-masked]>; [email-masked]
> Subject: Re: New draft-vasilenko-6man-nd-mitm-protection-00.txt
> 
> On 30/9/20 10:32, Vasilenko Eduard wrote:
> > Hi Philip,
> > DHCP snooping support on IPv4 was important discussion topic 20-25 years
> ago.
> > I strongly suspect that it would be difficult to find any vendor that could not
> snoop DHCPv4 (and filter ARP after this based on DHCP offers from trusted
> port).
> > It is probably possible to find vendor who has not implemented yet DHCPv6
> snooping, but because it is easy to do - I do assume that IPv6 world would finish
> the replication of this practice. It is just a question for how many enterprises
> have moved to IPv6 - they would create the pressure for vendors.
> 
> DHCPv6 snooping is not necessarily trivial (see RFC7610). Similarly, the way most
> vendors implement RA-Guard, is trivially evasible (see RFC7113).
> 
> 
> > Major vendors support DHCPv6 snooping (then could filter ND NA):
> >
> https://support.huawei.com/enterprise/en/doc/EDOC1000141942/fd2f4475/co
> nfiguring-basic-functions-of-dhcp-snooping
> >
> > SLAAC is the real problem, because nothing to snoop to understand who was
> the first to claim particular GUA/ULA IPv6 (it is local and distributed decision on
> hosts). Filtering table would be extremely difficult to create (read RFC 6602 SAVI
> to see the complexity level).
> > If we would like for IPv6 world should just replicate IPv4 (but bigger IP
> address), then nothing should be done (this draft does not make sense) - SLAAC
> should not be used - it would resolve NA ND security problem.
> > I am doubt that any business would agree to use SLAAC with such security
> hole. SLAAC would be left for ISP broadband services only.
> > It is effectively "implicit SLAAC deprecation strategy".
> 
> Whether one likes it or not, SLAAC is mandatory, and is the only
> mechanism that you can use to configure Android phones. So no, there's
> no way SLAAC will be deprecated.
> 
> Thanks,
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 1 Oct 2020 09:39:11 +0000

Fernando,
You are claiming too that all security problems should be resolved at once (as a one package of standards).
It is not possible in real life. The elephant could be eaten only by pieces.
Or else we would have unsecure SLAAC environment that would be finally rejected by the business (they would vote by money).
I do suspect that it already very close to reality, because DHCP is more popular in Enterprises that already moved to IPv6.

In respect to mentioned below problems - we have the standard solution for all of them.
We do not have solution just for rogue-NA.

OK. Tell me what would be the problem with rogue-RA if vendor would implement RA-Guard with extended checks that you proposed in RFC 7113?
And then (assume only legal routers on the link) what could be the problem with redirects?

Eduard
> From: Fernando Gont [mailto:[email-masked]]
> Sent: 30 сентября 2020 г. 22:31
> To: Vasilenko Eduard <[email-masked]>; Fernando Gont
> <[email-masked]>; [email-masked]
> On 28/9/20 12:21, Vasilenko Eduard wrote:
> [...]
> > You do use term "hijack" in this document for the leakage of information.
> 
> What you are doing is hijacking. It's not called "information leakage".
> 
> 
> > In reality "hijack" is about intercepting active flows that is not effective
> anymore on 70-80% of encrypted traffic (except very vulnerable DNS still not
> encrypted in majority of cases).
> 
> Hijacking is having the attacker get the packets that he otherwise not get.
> SImilar to BGP hijacks.
> 
> 
> [...]
> > My draft discusses the problem of "rogue NA" much deeper (20x) and proposes
> solution on ND level.
> 
> You are not solving any problem if you don't fix: RA-based bectors,
> NS-based vectors, ICMPv6 Redirects, and NA-based vectors.
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [email-masked]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
>

---

From: Philip Homburg <[email-masked]>
Date: Thu, 01 Oct 2020 12:39:28 +0200

> You are claiming
> too that all security problems should be resolved at once (as a
> one package of standards).  It is not possible in real life. The
> elephant could be eaten only by pieces.  

As discussed before, your solution doesn't actually provide any 
security without L2 filtering.

So this is not a case of trying to solve all security problems at once,
this a case of not solving any security problemt all.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 1 Oct 2020 11:19:20 +0000

> So this is not a case of trying to solve all security problems at once, this a case of
> not solving any security problemt all.

How else to protect against rogue-NA messages?

> From: [email-masked] [mailto:pch-b9D3CB0F5@u-
> 1.phicoh.com] On Behalf Of Philip Homburg
> Sent: 1 октября 2020 г. 13:39
> To: [email-masked]
> Cc: Vasilenko Eduard <[email-masked]>
> > too that all security problems should be resolved at once (as a one
> > package of standards).  It is not possible in real life. The elephant
> > could be eaten only by pieces.
> 
> As discussed before, your solution doesn't actually provide any security without
> L2 filtering.
> 
> So this is not a case of trying to solve all security problems at once, this a case of
> not solving any security problemt all.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Oct 2020 13:27:50 +0200 (CEST)

> I do suspect that it already very close to reality, because DHCP is more popular in Enterprises that already moved to IPv6.

Most people I have talked to who have claimed to have an absolute need for 
DHCP for "accounting" and "security tracking" purposes, actually don't 
deploy SAVI. So their activity is a checkbox activity with minimal 
improvement to security as it's easy to spoof anyway.

To give feedback to your document, I think you should put SAVI at the 
front of the introduction. This is the real solution. However, if the 
switch only has partial SAVI support, then your proposal might come into 
play. Then you should write what L2 functionality is required (minimum) 
together with your enhancement, to actually make it safe.

There is no way to solve L3 using only L3, since L3 is carried by L2. To 
make L3 secure and proof against MITM etc, you need to secure both. So if 
you could add to your document what L2 mechanisms are needed plus your L3 
proposal to actually make everything (more) secure, I think that'd help.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 1 Oct 2020 11:37:22 +0000

Hello Fernando

> >> If you consider RA-guard a mitigation for RA-based attacks, then,
> >> things like "First Hop Security"/ND inspection/SAVI would solve the ND
> counterpart.
> > I have not understood what you mean by "First Hop Security"/ND inspection"
> - it looks as very general term.
> 
> See e.g.:
> https://www.cisco.com/c/en/us/td/docs/ios-
> xml/ios/ipv6_fhsec/configuration/15-sy/ip6-nd-inspect.html

As you point out, this 10 years-old approach mitigates ND attacks including the ones addressed here.  It's interesting that 20 years old problems keep resurfacing in new drafts. The world has moved on and 6MAN was left behind.

Still you'll find that we do a number of internal tricks, inclusion transformations of the frames and "intelligent" frame drops, that were not discussed / validated by the community. This yields its own dangers so yes, it's not an ideal situation. I know, I wrote a good deal of that code.

ND inspection is based in snooping and would benefit from a real interface with the host. We saw that in the GRAND discussion, another trick like the one proposed because the base ND is outdated. How many till this group wakes up? 

Now, there is second chance to reconciliate the needs of the real world and the work at 6MAN. We all know what shape ND needs to have in a modern managed network. And it's not reactive.

Keep safe;

Pascal

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 1 Oct 2020 11:45:46 +0000

Hi Mikael,
Your both requests look reasonable for me:
1. More comparison to SAVI. I have very small reference to SAVI now (only interoperability section).
2. More references to other protection techniques that would be probably needed.
I have now clear reference about RA-guard need.
I do not have reference to DHCP-shield that is probably wrong.

It would be in the next version.
Eduard
> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: 1 октября 2020 г. 14:28
> To: Vasilenko Eduard <[email-masked]>
> Cc: [email-masked]
> Subject: RE: New draft-vasilenko-6man-nd-mitm-protection-00.txt
> 
> > Or else we would have unsecure SLAAC environment that would be finally
> rejected by the business (they would vote by money).
> > I do suspect that it already very close to reality, because DHCP is more popular
> in Enterprises that already moved to IPv6.
> 
> DHCP for "accounting" and "security tracking" purposes, actually don't deploy
> SAVI. So their activity is a checkbox activity with minimal improvement to
> security as it's easy to spoof anyway.
> 
> To give feedback to your document, I think you should put SAVI at the front of
> the introduction. This is the real solution. However, if the switch only has partial
> SAVI support, then your proposal might come into play. Then you should write
> what L2 functionality is required (minimum) together with your enhancement, to
> actually make it safe.
> 
> There is no way to solve L3 using only L3, since L3 is carried by L2. To make L3
> secure and proof against MITM etc, you need to secure both. So if you could
> add to your document what L2 mechanisms are needed plus your L3 proposal to
> actually make everything (more) secure, I think that'd help.
> 
> --

---

From: Philip Homburg <[email-masked]>
Date: Thu, 01 Oct 2020 14:23:28 +0200

>As you point out, this 10 years-old approach mitigates ND attacks including 
>the ones addressed here.  It's interesting that 20 years old problems keep r
>esurfacing in new drafts. The world has moved on and 6MAN was left behind.

That is nice, but somebody should at least write down the algorithm/protocol.

It not clear to me to what extent L2 filtering is within the scope of 6man.

Personally I don't know if this is such a great problem to solve. We 
are quickly moving to a world where just about all traffic is encrypted. So
a local attacker can learn the remote IP addreses contacted by a host but
not much more. When this is a serious concern, for example at a public wifi,
a VPN is good solution to that problem. Note that a rogue wifi operator can
collect all traffic information anyhow, no matter what changes we make to ND.

Then the downsides. I once bumped into a situation at a conference where
the ARP filtering feature only allowed 1 IPv4 address. It took me a lot of
time figure out why my VMs had working IPv6, but no IPv4. Note they did get
DHCPv4 leases, it just didn't work.

This can also happen with any kind of IPv6 filtering: if a host exceeds the
limit of what the L2 devices can handle, then you get an almost imposible to
debug situation.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 1 Oct 2020 12:48:47 +0000

> Personally I don't know if this is such a great problem to solve. We are quickly
> moving to a world where just about all traffic is encrypted.

It does not help too much for internal Enterprise traffic, because server key should be checked in trusted certification authority.
The battle who is considered trusted is very political.
User would accept any pop up window with the request about key.
Hence, any MITM is still the same dangerous as 20 years ago.

> From: ipv6 [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: 1 октября 2020 г. 15:23
> To: [email-masked]
> Cc: Pascal Thubert (pthubert) <pthubert=[email-masked]>
> >As you point out, this 10 years-old approach mitigates ND attacks
> >including the ones addressed here.  It's interesting that 20 years old
> >problems keep r esurfacing in new drafts. The world has moved on and 6MAN
> was left behind.
> 
> Personally I don't know if this is such a great problem to solve. We are quickly
> moving to a world where just about all traffic is encrypted. So a local attacker
> can learn the remote IP addreses contacted by a host but not much more. When
> this is a serious concern, for example at a public wifi, a VPN is good solution to
> that problem. Note that a rogue wifi operator can collect all traffic information
> anyhow, no matter what changes we make to ND.
> 
> Then the downsides. I once bumped into a situation at a conference where the
> ARP filtering feature only allowed 1 IPv4 address. It took me a lot of time figure
> out why my VMs had working IPv6, but no IPv4. Note they did get
> This can also happen with any kind of IPv6 filtering: if a host exceeds the limit of
> what the L2 devices can handle, then you get an almost imposible to debug
> situation.
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Thu, 1 Oct 2020 11:43:22 -0300

Hello, Pascal,

On 1/10/20 08:37, Pascal Thubert (pthubert) wrote:
> Hello Fernando
> 
>>>> If you consider RA-guard a mitigation for RA-based attacks,
>>>> then, things like "First Hop Security"/ND inspection/SAVI would
>>>> solve the ND
>> counterpart.
>> See e.g.: https://www.cisco.com/c/en/us/td/docs/ios- 
> including the ones addressed here.  It's interesting that 20 years
> old problems keep resurfacing in new drafts.

It is interesting, but not surprising. The only project that I know of
that tried to do a comprehensive security assessment of the IPv6
protocols was one carried out by the UK CPNI, on which I was involved.

The results of that (long) project were brought piecemeal in most of the
I-Ds I've published since 2010 or so.

> The world has moved on and 6MAN was left behind.
> 
> Still you'll find that we do a number of internal tricks, inclusion
> transformations of the frames and "intelligent" frame drops, that
> were not discussed / validated by the community. This yields its own
> dangers so yes, it's not an ideal situation. I know, I wrote a good
> deal of that code.

Of course it is not. ND is inherently insecure. SO whatever you
implement on a switch is necessarily going to be a hack, one way or
another -- and as smart as the hacks may be.

> ND inspection is based in snooping and would benefit from a real
> interface with the host. We saw that in the GRAND discussion, another
> trick like the one proposed because the base ND is outdated. How many
> till this group wakes up?
> 
> Now, there is second chance to reconciliate the needs of the real
> world and the work at 6MAN. We all know what shape ND needs to have
> in a modern managed network. And it's not reactive.

Just a clarification, in case my emails came across differently:

* I'm all for improvements, no matter how major the changes may be. Most 
of IPv6 is ~25 years old, and one would assume that we have all learned 
some lessons and gained deployment experience since them. -- so 
improvements are natural.

* My comment to Eduard is that if one focuses on a single attack vector, 
as in this case, it's equivalent to e.g. proposing that cars have 
pressurized cabins, so that they would be more prepared to fly -- when 
the car would never actually fly (by design).

* If there was an indication that one particular vector was way more 
critical than all others, and that mitigating one specific vector would 
  buy us any concrete benefits (or prevent very bath pathological 
cases), then I'd be all for it. OTOH, if one is going to address a 
single vector, without any chance that the other vectors are addressed 
(because they are inherent to the design of the protocol), then that 
feels a lot like a noop to me.

Thanks,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 1 Oct 2020 14:48:25 +0000

I'm perfectly good with this Fernando. 

Pascal

> From: Fernando Gont <[email-masked]>
> Sent: jeudi 1 octobre 2020 16:43
> To: Pascal Thubert (pthubert) <[email-masked]>; Vasilenko Eduard
> <[email-masked]>; Fernando Gont <[email-masked]>;
> Xipengxiao <[email-masked]>; [email-masked]
> > problems keep resurfacing in new drafts.
> 
> It is interesting, but not surprising. The only project that I know of that tried to
> do a comprehensive security assessment of the IPv6 protocols was one carried
> out by the UK CPNI, on which I was involved.
> 
> The results of that (long) project were brought piecemeal in most of the I-Ds
> I've published since 2010 or so.
> 
> 
> > transformations of the frames and "intelligent" frame drops, that were
> > not discussed / validated by the community. This yields its own
> Of course it is not. ND is inherently insecure. SO whatever you implement on a
> switch is necessarily going to be a hack, one way or another -- and as smart as
> the hacks may be.
> 
> 
> 
> > world and the work at 6MAN. We all know what shape ND needs to have in
> > a modern managed network. And it's not reactive.
> 
> * I'm all for improvements, no matter how major the changes may be. Most of
> IPv6 is ~25 years old, and one would assume that we have all learned some
> lessons and gained deployment experience since them. -- so improvements are
> natural.
> 
> * My comment to Eduard is that if one focuses on a single attack vector, as in
> this case, it's equivalent to e.g. proposing that cars have pressurized cabins, so
> that they would be more prepared to fly -- when the car would never actually
> fly (by design).
> 
> * If there was an indication that one particular vector was way more critical
> than all others, and that mitigating one specific vector would
>   buy us any concrete benefits (or prevent very bath pathological cases), then
> I'd be all for it. OTOH, if one is going to address a single vector, without any
> chance that the other vectors are addressed (because they are inherent to the
> design of the protocol), then that feels a lot like a noop to me.
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 1 Oct 2020 15:13:46 +0000

It is very strange consensus on 6man (may be only for me): "ND is extremely unsecure and noting could be done about it. We have explained it in RFC for "trusted model". Amen."
This vehicle is not possible to fix.
At least 4 experts (from 5 commenting) have given this message.
Then we really need different ND.

Fernando,
I am proposing how to block the last unresolved leakage of information: from rogue-NA.
Other cases for Information leakage are resolved by different other standards. Well, may be not all vendors implemented it properly, but it is different story.
If leakage of information is not important, then what could be important?!?

Ed/
> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: 1 октября 2020 г. 17:48
> To: Fernando Gont <[email-masked]>; Vasilenko Eduard
> Xipengxiao <[email-masked]>; [email-masked]
> > The results of that (long) project were brought piecemeal in most of
> > the I-Ds I've published since 2010 or so.
> >
> >
> > > interface with the host. We saw that in the GRAND discussion,
> > > another trick like the one proposed because the base ND is outdated.
> > > How many till this group wakes up?
> > >
> > IPv6 is ~25 years old, and one would assume that we have all learned
> > * My comment to Eduard is that if one focuses on a single attack
> > vector, as in this case, it's equivalent to e.g. proposing that cars
> > have pressurized cabins, so that they would be more prepared to fly --
> > when the car would never actually fly (by design).
> >
> > (because they are inherent to the design of the protocol), then that feels a lot
> like a noop to me.
> >
> > Thanks,
> > --
> > Fernando Gont
> > SI6 Networks

---

From: Philip Homburg <[email-masked]>
Date: Thu, 01 Oct 2020 17:13:49 +0200

In your letter dated Thu, 1 Oct 2020 11:19:20 +0000 you wrote:
>> So this is not a case of trying to solve all security problems at once, t=
>his a case of

Just a random example solution:
when a device does DAD, the L2 devices sends the IPv6 address and MAC
address to a central location. If the IPv6 and the MAC are not in use on
a different port then the central service sends an OK back to the switch.
The switch now allows the host to use the IPv6 address and the MAC address
in IPv6 traffic.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 01 Oct 2020 17:17:34 +0200

> It does not help too much for internal Enterprise traffic, because
> server key should be checked in trusted certification authority.
> The battle who is considered trusted is very political.  User would
> accept any pop up window with the request about key.  Hence, any
> MITM is still the same dangerous as 20 years ago.

Put all enterprise services behind a VPN. 

Note that the owner of a public wifi can also launch a MITM attack. A public
wifi may also have security problems or just a general lack of security
(i.e. no RA-guard). So if your users are likely to accept bad certificates
then you have to use a VPN anyhow.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 1 Oct 2020 15:23:22 +0000

Hi Philip,
Yes, the similar variation XiPeng has proposed in our discussions.
The difference was: instead of proxy by switch, just ask router to connect to all NS multicast groups (to see who is 1st).

If it would be the group consensus - I am ready to change the draft.

Just 1 problem: router should become the master - keep all states.
It is not SLAAC anymore.
I did strongly suspect that WG would not agree to this.

I personally like the idea to move to more centralize repository for all "bindings".

Eduard
> Sent: 1 октября 2020 г. 18:14
> To: [email-masked]
> address to a central location. If the IPv6 and the MAC are not in use on a
> different port then the central service sends an OK back to the switch.
> The switch now allows the host to use the IPv6 address and the MAC address in
> IPv6 traffic.
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 1 Oct 2020 15:29:38 +0000

Philip,
It is possible to assume that all Enterprise applications are exposed to public. Then you need encryption (that is easy) and key management (that is very difficult).
TLS everywhere (inside and outside) is the great concept.
But the majority of Enterprises still have notion "Intranet" where they do not use encrypted VPN.
Why they would not move to TLS everywhere?
1. Key management burden
2. 1M of old applications that do not support it properly
Eduard
> Sent: 1 октября 2020 г. 18:18
> To: [email-masked]
> > accept any pop up window with the request about key.  Hence, any MITM
> > is still the same dangerous as 20 years ago.
> 
> Note that the owner of a public wifi can also launch a MITM attack. A public wifi
> may also have security problems or just a general lack of security (i.e. no RA-
> guard). So if your users are likely to accept bad certificates then you have to use
> a VPN anyhow.
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 1 Oct 2020 12:52:50 -0300

On 1/10/20 12:13, Vasilenko Eduard wrote:
> It is very strange consensus on 6man (may be only for me): "ND is
> extremely unsecure and noting could be done about it. We have
> explained it in RFC for "trusted model". Amen." 

I don't think that represents consensus (there wasn't a consensus call 
on the topic, for instance).

> This vehicle is not
> possible to fix. At least 4 experts (from 5 commenting) have given
> this message. Then we really need different ND.

If these issues are considered a problem, and the operational 
mitigations that the industry has somehow developed (ND inspection, 
RA-guard, DHCPv6-snooping) are deemed as inadequate or not good enough, 
then yes, we'd need something different.

(If you want to fly, you better get a plane rather than try to improve 
the aerodynamics of a car)

> Fernando, I am proposing how to block the last unresolved leakage of
> information: from rogue-NA. Other cases for Information leakage are
> resolved by different other standards. 

You either solve the problem at the protocol, or operationally.

It doesn't make much sense to fix a single hole in the protocol, on the 
premise that the network fixes the rest.

If you are concerned about this problem, then:

* If you are the network, you cannot rely on hosts mitigating this 
specific vector.

* If you are the host, you cannot rely on the network mitigating the rest.

Non-circumventable RA-Guard deployment is not widespread, as far as I 
can tell, for instance.

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Thu, 1 Oct 2020 21:46:07 +0200

In the context of WIFI what isn’t solved with DHCP for address assignment and one of co-locating AP with router and do L2 unicast, or use of a WLC or AP that snoops and does L2 multicast to unicast rewrite?

Aka, don’t pretend WIFI is a thick yellow cable. 

Cheers,
Ole

> On 1 Oct 2020, at 17:23, Vasilenko Eduard <[email-masked]> wrote:
> 
> Hi Philip,

---

From: Mark Smith <[email-masked]>
Date: Fri, 2 Oct 2020 10:05:14 +1000

On Fri, 2 Oct 2020, 05:46 Ole Troan, <[email-masked]> wrote:

> In the context of WIFI what isn’t solved with DHCP for address assignment
> and one of co-locating AP with router and do L2 unicast, or use of a WLC or
> AP that snoops and does L2 multicast to unicast rewrite?
>

That's fundamentally the problem I think.

The IEEE made it look like 'thick yellow cable' e.g. emulate Ethernet by
using the frame type, but didn't emulate it well enough e.g. give it the
same multicast/broadcast characteristics as yellow cables.

It's different enough that it would have been better if it didn't pretend
it was Ethernet, and e.g. had a different frame format to make the
difference clear.

Regards,
Mark.

> > The difference was: instead of proxy by switch, just ask router to
> connect to all NS multicast groups (to see who is 1st).
> >

---

From: Ole Troan <[email-masked]>
Date: Fri, 2 Oct 2020 08:09:30 +0200

> On 2 Oct 2020, at 02:05, Mark Smith <[email-masked]> wrote:
> 
> 
> 
> 
> The IEEE made it look like 'thick yellow cable' e.g. emulate Ethernet by using the frame type, but didn't emulate it well enough e.g. give it the same multicast/broadcast characteristics as yellow cables.

You can deploy WIFI as a L3 hub and spoke topology (set of point to point links).
That’s mostly an implementation and operational choice. You could even support SLAAC (although with a /64 per host)

It would break protocols that depend on nodes being in the same broadcast domain. Like mdns. Probably best broken anyway. :-)

> It's different enough that it would have been better if it didn't pretend it was Ethernet, and e.g. had a different frame format to make the difference clear.

Cheers 
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 2 Oct 2020 07:12:58 +0000

I agree with that.

The emulation was critical in the early days to kick off Wi-Fi. That is probably what enabled the technology to become the pervasive thing we see around us.

But the more we increase speed and density and the more the difference shows.

If we want to keep the success of Wi-Fi growing, it’s time to take some efforts and adapt IPv6 operations for it.

As usual it started with proprietary effort, that transforms the frames and the packets and limits their scope. More or less hideous things have been done to frames and packets by middle boxes, switches and routers. Rewriting MAC addresses and dropping packets being the least of that.

But I believe in standards.

Keep safe;

Pascal

From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: vendredi 2 octobre 2020 02:05
To: Ole Troan <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: New draft-vasilenko-6man-nd-mitm-protection-00.txt

On Fri, 2 Oct 2020, 05:46 Ole Troan, <[email-masked]<mailto:[email-masked]>> wrote:
In the context of WIFI what isn’t solved with DHCP for address assignment and one of co-locating AP with router and do L2 unicast, or use of a WLC or AP that snoops and does L2 multicast to unicast rewrite?

Regards,
Mark.

Cheers,
Ole

> On 1 Oct 2020, at 17:23, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Philip,
>> From: [email-masked]<mailto:[email-masked]> [mailto:pch-b9D3CB0F5@u-<mailto:pch-b9D3CB0F5@u->
>> 1.phicoh.com<http://1.phicoh.com>] On Behalf Of Philip Homburg
>> To: [email-masked]<mailto:[email-masked]>
>> Cc: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 2 Oct 2020 07:21:43 +0000

Just frame structure is not important. AP needs to re-write it anyway. You could think even today that Ethernet frame on the air is different from Ethernet frame on the wire.

Only not proper emulation for multicast and not efficient broadcast are problems.

From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 2 октября 2020 г. 10:13
To: Mark Smith <[email-masked]>; Ole Troan <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: RE: New draft-vasilenko-6man-nd-mitm-protection-00.txt

I agree with that.

Keep safe;

Pascal

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Mark Smith
Sent: vendredi 2 octobre 2020 02:05
To: Ole Troan <[email-masked]<mailto:[email-masked]>>
Cc: 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: New draft-vasilenko-6man-nd-mitm-protection-00.txt

Regards,
Mark.

Cheers,
Ole

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 2 Oct 2020 08:45:32 +0000

I am not sure that I have understood Ole and Mark by 100%.

But it looks you are discussion here is the same that Ted Lemon has proposed yesterday: “to simply capture multicasts on the base station and do proxy nd there without changes on the host”. Just Ole additionally mentioned DHCP (that should give stateful database).

Pascal has answered ”It was starting point. In that process, we found limits, and designed the registration to address those. ND is not very explicit about what's going on and it is hard to differentiate some valid situations from attacks. Messages can be missed. Hosts can be silent. Not all multicast can be filtered.”

IMHO: such solution (DHCP + multicast conversion into unicast on AP) should drastically decrease Multicast/Broadcast problem. Probably to the point that we do not need new ND for WiFi hosts.

Moreover, DHCP centralized database would greatly help in security filtering.

I believe that Prefix announcement with L bit 0 could improve the situation too (let’s treat WiFi as NBMA, because WiFi is not good for multicast and broadcast).

I do not see the problem with big L2 domains for the above (to avoid roaming). Just connect it by any L2 VPN.
L2 VPN choice could be very disputable here (EVPN? WiND?), but it is really the separate question.

Unfortunately, It would not solve the problem for low powered technologies where host would need to sleep.
Router should become more clever proxy in this case that would drive us to not compatible version of ND for hosts –
they need to announce the reason for wake-up (what they are really interested to listen) and the timer for wake-up (for router to finally check that they are not dead).
If we would assume that all hosts on the link are uniform (not good assumption) then it is possible to have this “timer” and “reason” as the local information to the router.
May be it is not the bad compromise for not to change hosts?

Ed/
From: Ole Troan [mailto:[email-masked]]
Sent: 2 октября 2020 г. 9:10
To: Mark Smith <[email-masked]>
Cc: Vasilenko Eduard <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: New draft-vasilenko-6man-nd-mitm-protection-00.txt

On 2 Oct 2020, at 02:05, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

Cheers
Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 02 Oct 2020 12:25:35 +0200

> Yes, the
> similar variation XiPeng has proposed in our discussions.  The
> difference was: instead of proxy by switch, just ask router to

As was discussed before, you need to operate at L2 to get security, just
making changes at L3 doesn't cut it.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 02 Oct 2020 12:32:00 +0200

> It is possible
> to assume that all Enterprise applications are exposed to public.
> Then you need encryption (that is easy) and key management (that
> is very difficult).  TLS everywhere (inside and outside) is the
> great concept.  But the majority of Enterprises still have notion
> "Intranet" where they do not use encrypted VPN.  Why they would
> not move to TLS everywhere? 1. Key management burden 2. 1M of old
> applications that do not support it properly 

A VPN doesn't need changes to applications. 

If your applications are not encrypted, you don't use a VPN, and
the threat model includes bad actors that can spoof MAC addresses then you
are in a serious risk without L2 filtering.

On the other hand, if you assume that the 'intranet' is safe then no (security)
changes are needed for ND.

---

From: Ole Troan <[email-masked]>
Date: Fri, 2 Oct 2020 12:42:32 +0200

> On 2 Oct 2020, at 10:45, Vasilenko Eduard <[email-masked]> wrote:
> 

No I was not thinking of a ND proxy in my solution. 
Let me write it down in more details after weekend. 

Cheers,
Ole

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 2 Oct 2020 14:36:45 +0000

Hi Philip,
I believe that it is not good idea to say that security is the "application problem only" - it should have proper encryption and key management.
Networks layer should be additional layer for security.
Good Security in general is like onion: many perimeters of protection. If Intruder has success with one perimeter - he should have the problem with next one.

I have given you the example that many mechanisms against MAC spoofing exists - the admin who really cares about security has tools.
Eduard
> Sent: 2 октября 2020 г. 13:32
> To: [email-masked]
> > Then you need encryption (that is easy) and key management (that is
> > very difficult).  TLS everywhere (inside and outside) is the great
> > concept.  But the majority of Enterprises still have notion "Intranet"
> > where they do not use encrypted VPN.  Why they would not move to TLS
> > everywhere? 1. Key management burden 2. 1M of old applications that do
> > not support it properly
> 
> If your applications are not encrypted, you don't use a VPN, and the threat
> model includes bad actors that can spoof MAC addresses then you are in a
> serious risk without L2 filtering.
>

---

From: Philip Homburg <[email-masked]>
Date: Fri, 02 Oct 2020 16:50:37 +0200

> I believe that
> it is not good idea to say that security is the "application problem
> only" - it should have proper encryption and key management.
> Networks layer should be additional layer for security.  Good
> Security in general is like onion: many perimeters of protection.
> If Intruder has success with one perimeter - he should have the
> problem with next one.

That's why I said that the way to solve local network security problem is to
use a VPN. This makes it easy for the network admin to only allow known
hosts, or kick out hosts that don't have required security patches. It
provides an encrypted and authentical channel between the host and the
enterprise network.

Note that, if you want to secure the local subnet and have the require L2
filtering in place, then (as I described in an earlier message), it is easy
to extend this L2 filtering to include IPv6 addresses as well.

In short, the ND protocol is for many reasons not the right place to provide
security.

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 2 Oct 2020 14:54:43 +0000

> it is easy to extend this L2 filtering to include IPv6 addresses as well.
It is not possible now to create filtering table for Rogue-NA. No master port of master binding database to snoop.

> Sent: 2 октября 2020 г. 17:51
> To: [email-masked]
> > Networks layer should be additional layer for security.  Good Security
> > in general is like onion: many perimeters of protection.
> That's why I said that the way to solve local network security problem is to use a
> VPN. This makes it easy for the network admin to only allow known hosts, or
> kick out hosts that don't have required security patches. It provides an encrypted
> and authentical channel between the host and the enterprise network.
> 
> filtering in place, then (as I described in an earlier message), it is easy to extend
> this L2 filtering to include IPv6 addresses as well.
>

---

From: Philip Homburg <[email-masked]>
Date: Fri, 02 Oct 2020 17:07:47 +0200

> It is not possible now to create filtering table for Rogue-NA. No
> master port of master binding database to snoop.

If the model is that the first host to use an IPv6 address takes ownership
of that address, then such a database can be built easily with ND snooping.

Such a database can be pre-populated with static IPv6 addresses and their
corresponding MAC addresses.

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 2 Oct 2020 15:27:40 +0000

Static ND bindings is the solution indeed. Is everybody agree to it?

ND snooping for "who was the 1st" is SAVI RFC 6620.
It is complex - look RFC.
It is not just snooping - it is additionally proxy check by switch.
And it does not block the situation when 1st was the Intruder (server was in reload) - SAVI does not block MITM of this type.
Hence, I have shown statistics - 3 vendors support.
But in principle you could say that "SAVI is enough". Are you sure?

Ed/
> Sent: 2 октября 2020 г. 18:08
> To: [email-masked]
> If the model is that the first host to use an IPv6 address takes ownership of that
> address, then such a database can be built easily with ND snooping.
>

---

From: Philip Homburg <[email-masked]>
Date: Fri, 02 Oct 2020 17:48:14 +0200

>It is not just snooping - it is additionally proxy check by switch.

SAVI is one particular implementation of this concept. There can be others,
each with their own advantages and disadvantages.

>And it does not block the situation when 1st was the Intruder (server was i=
>n reload) - SAVI does not block MITM of this type.

It seems that the SAVI rfc doesn't not discuss what to do with static
addresses. But no doubt that can be added.

>But in principle you could say that "SAVI is enough". Are you sure?

SAVI is one solution to this problem. If SAVI has operational problems then
no doubt another solutions can be tried.

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 2 Oct 2020 15:57:26 +0000

Philip,
Therefore, Is your opinion that security problems related to address resolution SHOULD be resolved on L2?
Even if it could be that better solution on ND itself.

It is additional security complexity on switches vs additional complexity on routers.
Routers have more resources to do it properly and involved into ND anyway.

Eduard
> Sent: 2 октября 2020 г. 18:48
> To: [email-masked]
> SAVI is one particular implementation of this concept. There can be others, each
> with their own advantages and disadvantages.
> 
> >And it does not block the situation when 1st was the Intruder (server
> >was i= n reload) - SAVI does not block MITM of this type.
> 
> It seems that the SAVI rfc doesn't not discuss what to do with static addresses.
> But no doubt that can be added.
> 
> SAVI is one solution to this problem. If SAVI has operational problems then no
> doubt another solutions can be tried.
>

---

From: [email-masked]
Date: Tue, 6 Oct 2020 14:34:35 +0200

Hi Vasilenko, et al,

The ideas I had for how you could simplify (or mostly remove) ND operation on a link here:

A new version of I-D, draft-troan-6man-p2p-ethernet-00.txt
has been successfully submitted by O. Troan and posted to the
IETF repository.

Name:		draft-troan-6man-p2p-ethernet
Revision:	00
Title:		IP Point to Point Ethernet subnet model
Document date:	2020-10-06
Group:		Individual Submission
Pages:		7
URL:           https://www.ietf.org/id/draft-troan-6man-p2p-ethernet-00.txt
Status:        https://datatracker.ietf.org/doc/draft-troan-6man-p2p-ethernet/
Htmlized:      https://datatracker.ietf.org/doc/html/draft-troan-6man-p2p-ethernet
Htmlized:      https://tools.ietf.org/html/draft-troan-6man-p2p-ethernet-00

Abstract:
  Ethernet topology is no longer a shared medium.  It is a long time
  since Ethernet has been a thick yellow cable snaking its way from
  station to station.  Ethernet is now effectively deployed in a hub
  and spoke topology.  With a point to point link between a host and
  the network device.  This memo describes a set of simplications for
  how to run IP over such links, where the physical topology is exposed
  in the network layer topology.

Cheers,
Ole

> On 2 Oct 2020, at 12:42, Ole Troan <[email-masked]> wrote:
> 
> 
>

---

From: Philip Homburg <[email-masked]>
Date: Tue, 06 Oct 2020 16:17:48 +0200

> A new version of I-D, draft-troan-6man-p2p-ethernet-00.txt has been
> successfully submitted by O. Troan and posted to the IETF repository.

One thing not mentioned is what happens if you add a new switch to an exiting
network. I guess the obvious solution is to use homenet, but maybe that
should be mentioned.

Any device that does tethering can also be a homenet router.

However that raise the question, how does the switch (or a device that does
tethering) know that it is in a homenet environment?

We can assume that many legacy bridges can not do IP routing. So I wonder
how to automatically switch to P2P mode. Of course, just isolating individual
links is enough to get security, no need for a P2P mode.

---

From: [email-masked]
Date: Tue, 6 Oct 2020 16:32:29 +0200

Hi Philip,

> network. I guess the obvious solution is to use homenet, but maybe that

You can't add another node to a point to point link of course. It's kinda limited to having two ends by definition. ;-)
Yes, I agree it should say something about extending this network. So far I was focusing on hosts attached to a router.
For router to router links, homenet is likely the most obvious solution. At least the solution that is properly specified, and that avoid most of the obvious hacks.

> tethering) know that it is in a homenet environment?

I'd avoid the term "switch" if by that you mean an ethernet bridge.

> links is enough to get security, no need for a P2P mode.

If you pushed IP to the edge on wired networks, yes you don't need p2p mode.
For wireless running in p2p mode it has quite some benefits in both security, simplicity and efficiency in reducing broadcast.

Best regards,
Ole