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

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 24 Sep 2020 14:03:47 +0000

Hi IPv6 Guru!
I have published new draft with the goal to block the leakage of information that is still easy by ND help.
References to IETF repository is below.

May be these 4 slides would help:
https://drive.google.com/file/d/1AB-XW12LROvYbW2LqQR_0z4l0pD38owp/view?usp=sharing

Your comments are very much needed.
Eduard
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 24 сентября 2020 г. 16:12
To: Xipengxiao <[email-masked]>; Vasilenko Eduard <[email-masked]>
Subject: New Version Notification for draft-vasilenko-6man-nd-mitm-protection-00.txt

A new version of I-D, draft-vasilenko-6man-nd-mitm-protection-00.txt
has been successfully submitted by Eduard Vasilenko and posted to the IETF repository.

Name:		draft-vasilenko-6man-nd-mitm-protection
Revision:	00
Title:		ND improvement to prevent Man-in-the-middle attack
Document date:	2020-09-24
Group:		Individual Submission
Pages:		19
URL:            https://www.ietf.org/id/draft-vasilenko-6man-nd-mitm-protection-00.txt
Status:         https://datatracker.ietf.org/doc/draft-vasilenko-6man-nd-mitm-protection/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vasilenko-6man-nd-mitm-protection
Htmlized:       https://tools.ietf.org/html/draft-vasilenko-6man-nd-mitm-protection-00

Abstract:
   Privacy protection is the bigger and bigger concern of many
   governments and public in general. ND has a few open man-in-the-
   middle attack vectors. MITM is considered among the most dangerous
   attack types because of information leakage. This document proposes
   minimal modifications for ND to protect IPv6 nodes against still
   open MITM attacks. It could be implemented gradually on any nodes,
   with the biggest benefit from support on routers.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Sep 2020 04:46:42 -0300

Hello, Eduard,

I have only skimmed through your slides and document, and have the 
following comments:

Your draft says that it mitigates MITM attacks. However, please note 
that you are targeting only NC-poisoning attacks, and not ND-based MITM 
in general.

An attacker still has a plethora of vectors for performing MITM including:

* Forging an RA advertising herself/himself as a higher-priority router.

* Forging an RA that advertises a /128 RIO for the victims address, 
which should override the on-link /64 route (longest-matching prefix rule)

* One would also expect that a forged ICMPv6 Redirect would install a 
/128 route which, as such, would trump the /64 on-link route

The bottom-line is that the trust model for IPv6 is that you trust all 
systems on the local network. As a result, and as noted, trying to 
mitigate only one particular vector while leaving the rest open will not 
buy you much (if anything).

An attacker normally just wants to get his/her job done, rather than 
exploiting one specific vector...

Thanks!

Regards,
Fernando

On 24/9/20 11:03, Vasilenko Eduard wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 
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: Fri, 25 Sep 2020 09:24:03 +0000

Hi Fernando,
It would be good if anybody would show me attack vector on NA that I have missed.

I have stated in the Introduction that RA MITM is solved by RA-Guard (RFC 6105). I have put RA out of the scope. I do not know how to do it better.
I am trying to fix only MITM from NA. Currently, it is easy to MITM any host on the link if any other host is compromised by different vulnerability.
If one perimeter is broken - no possibility to create additional challenge for Intruder.
It is radical difference from IPv4 where L2 device could help by DHCP snooping and ARP filtering. IPv6 has additional security hole here. It looks like I have patched it.
If you believe that information leakage could be left intact just because "ND is for trusted model only" - it is you opinion, well respected here.
Encrypted authentication has been rejected by the market. We are living in "ND is trusted model only" - it is all what we have.

About redirect:
If router would be compromised, then even encryption would not help, never to say RA-Guard. Does not matter how utterly "untrusted ND mode" would be chosen.
What you propose to do about it?

Eduard
> From: Fernando Gont [mailto:[email-masked]]
> Sent: 25 сентября 2020 г. 10:47
> To: Vasilenko Eduard <[email-masked]>; [email-masked]
> Subject: Re: New draft-vasilenko-6man-nd-mitm-protection-00.txt
> 
> Hello, Eduard,
> 
> I have only skimmed through your slides and document, and have the following
> comments:
> 
> Your draft says that it mitigates MITM attacks. However, please note that you
> are targeting only NC-poisoning attacks, and not ND-based MITM in general.
> 
> 
> * Forging an RA that advertises a /128 RIO for the victims address, which should
> override the on-link /64 route (longest-matching prefix rule)
> 
> > https://drive.google.com/file/d/1AB-
> XW12LROvYbW2LqQR_0z4l0pD38owp/view?usp=sharing
> >
> > Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >

---

From: Philip Homburg <[email-masked]>
Date: Fri, 25 Sep 2020 12:59:33 +0200

> I have
> published new draft with the goal to block the leakage of information
> that is still easy by ND help.  References to IETF repository is
> below.

I see one basic security issue with the current draft:

What if the Intruder starts sending packets with the MAC address of the
Intercepted Victim. Is your solution limited to networks that have strict,
per port MAC address filtering?

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 25 Sep 2020 11:59:38 +0000

Hi Philip, thanks for attention!
I have started section 4.2 from "Proposed solution does not need any additional functionality on link layer technology (no layer 2 features needed)".
I was solving only ND MITM problem. Looks like you are asking for bigger scope (L2 included).
Let's sssume that Intruder would not try to poison NC cache (no ND problem discussed in the draft).
Intruder could just send packets with victim's MAC (it would not work on WiFi, 802.1x because of strong encrypted authentication).
Then switch should be doing MAC flapping between different ports and some traffic would be sent to wrong destination, other traffic would be broadcasted and visible to everybody.
It is not MITM, but leakage of information is possible too. It is well known hacker tool.
1. It is L2 problem, not IP problem. It has some number of solutions at L2 (blocking of flapping ports, authentication on ports).
2. IPv4 and IPv6 are equal in the face of this problem. It exist for long time and has been patched enough before.
2. It is intrusive - legal host would be disturbed and seek for help from Admin. Not a nice tool for Intruder.
IMHO: it is far from ND (or even IP). Of course, I did not include it into the scope.
Eduard
> From: [email-masked] [mailto:pch-b9D3CB0F5@u-
> 1.phicoh.com] On Behalf Of Philip Homburg
> Sent: 25 сентября 2020 г. 14:00
> To: [email-masked]
> Cc: Vasilenko Eduard <[email-masked]>
> Intercepted Victim. Is your solution limited to networks that have strict, per port
> MAC address filtering?

---

From: Philip Homburg <[email-masked]>
Date: Fri, 25 Sep 2020 16:10:35 +0200

> I have started section 4.2 from "Proposed solution does
> not need any additional functionality on link layer technology (no
> layer 2 features needed)".  I was solving only ND MITM problem.
> Looks like you are asking for bigger scope (L2 included).  

An attacker looks at all available layers. So if there is a convenient L2
attack, then having extra protection at L3 doesn't do much.

Note that the proposed changes have little effect without RA-guard and
RA-guard is also typically a L2 technique: you have to filter individual
switch ports. IPv6 doesn't have any concept of switch ports.

So implicitly, you are already assuming L2 filtering techniques.

> Let's
> sssume that Intruder would not try to poison NC cache (no ND problem
> discussed in the draft).  Intruder could just send packets with
> victim's MAC (it would not work on WiFi, 802.1x because of strong
> encrypted authentication).  

802.1x deals with the transport of frames over a link. It doesn't deal with
what is a valid MAC addresses. My laptop has many VMs that are bridged to 
(at some locations) a 802.1x wifi connection. Those VMs all use their own
MAC addresses.

> Then switch should be doing MAC flapping
> between different ports and some traffic would be sent to wrong
> destination, other traffic would be broadcasted and visible to
> everybody.  

This is what happens on just about every ethernet.

> too. It is well known hacker tool.  

The net effect is that an attacker doesn't need to deal with ND, but
can use this L2 attack instead.

> 1. It is L2 problem, not IP
> problem. It has some number of solutions at L2 (blocking of flapping
> ports, authentication on ports).  

Your change is effective only if all of those changes are implemented.

We know that RA-guard is already rare. In my experience, dealing with MAC
address collisions is extremely rare.

The net effect is that it is not worth implementing your change because it
does not improve the security of realworld networks.

> IPv4 and IPv6 are equal in
> the face of this problem. It exist for long time and has been
> patched enough before.  

I don't understand what you mean with 'and has been patched enough before'.

In my experience, IPv4 networks are wide open to this type of attack. Maybe
you can cite some numbers on IPv4 networks that having protection to deal with
this type of attack.

> 2. It is intrusive - legal host would be
> disturbed and seek for help from Admin. Not a nice tool for Intruder.

Duplicate MACs are almost impossible to find. If the attacker would just
sample the victims traffic, then the victim may notice a general degradation
of the network, but is unlike to seek help.

> IMHO: it is far from ND (or even IP). Of course, I did not include

Attackers don't care about scope, they care about succesful attacks.
Erecting a gate in the middle of a field, may discourage people from attacking
the gate. But you have to consider the possibility that they just walk around.

See the classical image at the end of this blog post:
https://blog.rootshell.be/2013/03/25/are-you-using-nac-like-no-access-control/
(just the first one I found)

---

From: Xipengxiao <[email-masked]>
Date: Fri, 25 Sep 2020 14:43:30 +0000

Hi Philip,

Thank you very much for taking the timing to read the draft and provide feedback. I agree with most of your comments, except maybe the opinion that is expressed in the following statement: 

"An attacker looks at all available layers. So if there is a convenient L2 attack, then having extra protection at L3 doesn't do much."

This is like saying that "the bucket has so many holes it's not worth plugging any".  While I acknowledge that you indeed have a point,  it's not wrong to plug a hole.  I think it should even be encouraged :-)

XiPeng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: Friday, September 25, 2020 4:11 PM
To: [email-masked]
Subject: Re: New draft-vasilenko-6man-nd-mitm-protection-00.txt 

> I have started section 4.2 from "Proposed solution does not need any 
> additional functionality on link layer technology (no layer 2 features 
> needed)".  I was solving only ND MITM problem.

An attacker looks at all available layers. So if there is a convenient L2 attack, then having extra protection at L3 doesn't do much.

Note that the proposed changes have little effect without RA-guard and RA-guard is also typically a L2 technique: you have to filter individual switch ports. IPv6 doesn't have any concept of switch ports.

> encrypted authentication).

802.1x deals with the transport of frames over a link. It doesn't deal with what is a valid MAC addresses. My laptop has many VMs that are bridged to (at some locations) a 802.1x wifi connection. Those VMs all use their own MAC addresses.

> Then switch should be doing MAC flapping between different ports and 
> some traffic would be sent to wrong destination, other traffic would 
> be broadcasted and visible to everybody.

> It is not MITM, but leakage of information is possible too. It is well 

The net effect is that an attacker doesn't need to deal with ND, but can use this L2 attack instead.

We know that RA-guard is already rare. In my experience, dealing with MAC address collisions is extremely rare.

The net effect is that it is not worth implementing your change because it does not improve the security of realworld networks.

> the face of this problem. It exist for long time and has been patched 
> enough before.

In my experience, IPv4 networks are wide open to this type of attack. Maybe you can cite some numbers on IPv4 networks that having protection to deal with this type of attack.

> 2. It is intrusive - legal host would be disturbed and seek for help 
> from Admin. Not a nice tool for Intruder.

Duplicate MACs are almost impossible to find. If the attacker would just sample the victims traffic, then the victim may notice a general degradation of the network, but is unlike to seek help.

Attackers don't care about scope, they care about succesful attacks.
Erecting a gate in the middle of a field, may discourage people from attacking the gate. But you have to consider the possibility that they just walk around.

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 25 Sep 2020 16:29:48 +0000

Hi Philip,
I agree to what Xipeng said - it is the primary point. We could not fix all security problems in one standard. And open security hole in any other layer or protocol is not the reason to keep hole in other.
In the hope to solve everything at the same time. Later.

The only reasonable question could be: do we see any synergy between layers to leverage it.
In the case of MITM on NA - I do not see any synergy. Neither with L2, nor with anything else (TCP, Routing - could be many other things where is it possible to search for synergy).

This security patch are not dependent on L2 - no need for L2 assistance.
RA-guard are fully dependent on L2 - it is 100% switch assistance.
And yes, complete security solution should have RA-Guard. Hence, should have L2 assistance anyway.
Complete security solution for company should have much more then that.

I have 1 extra point: ND protocol is more vulnerable than former ARP,
Because it was possible to effectively assist to ARP from L2: snoop DHCP and filter ARPs.
It is not possible on ND because architecture is distributed.
Read 1st attack vector - how easy it is now. No any help from L2 is possible.
With this draft IPv6 security would get to the equal level with IPv4 on this aspect (ND/ARP).

I am reluctant to deep dive into L2 security. I believe that it is off-topic. But you push hard. OK.
Look here: https://support.huawei.com/enterprise/en/doc/EDOC1100004194/d8e87f9e/example-for-configuring-mac-address-flapping-detection
MAC address flapping result in blocking respective ports on the switch.
Or sticky MACs: https://support.huawei.com/enterprise/en/doc/EDOC1000178177/f077fec3/configuring-the-sticky-mac-address-function
Or better this one about MAC address authentication: https://support.huawei.com/enterprise/en/doc/EDOC1000141870/c5852f72/example-for-configuring-mac-address-authentication-to-control-user-access
You see: protection against MAC spoofing does exist.
The admin who really cares about security - could use it. Admin has nothing now for the case of NA MITM.

The fact that big proportion of Enterprise do not care too much about security
Is not an excuse for not to have the solution for others who really care.

Eduard
> From: ipv6 [mailto:[email-masked]] On Behalf Of Xipengxiao
> Sent: 25 сентября 2020 г. 17:44
> To: Philip Homburg <[email-masked]>; [email-masked]
> Subject: RE: New draft-vasilenko-6man-nd-mitm-protection-00.txt
> 
> Hi Philip,
> 
> Thank you very much for taking the timing to read the draft and provide
> feedback. I agree with most of your comments, except maybe the opinion that
> is expressed in the following statement:
> 
> "An attacker looks at all available layers. So if there is a convenient L2 attack,
> then having extra protection at L3 doesn't do much."
> 
> This is like saying that "the bucket has so many holes it's not worth plugging
> any".  While I acknowledge that you indeed have a point,  it's not wrong to plug
> a hole.  I think it should even be encouraged :-)
> 
> XiPeng
> 
> An attacker looks at all available layers. So if there is a convenient L2 attack,
> then having extra protection at L3 doesn't do much.
> 
> Note that the proposed changes have little effect without RA-guard and RA-
> guard is also typically a L2 technique: you have to filter individual switch ports.
> IPv6 doesn't have any concept of switch ports.
> 
> 802.1x deals with the transport of frames over a link. It doesn't deal with what is
> a valid MAC addresses. My laptop has many VMs that are bridged to (at some
> locations) a 802.1x wifi connection. Those VMs all use their own MAC addresses.
> 
> The net effect is that it is not worth implementing your change because it does
> not improve the security of realworld networks.
> 
> Duplicate MACs are almost impossible to find. If the attacker would just sample
> the victims traffic, then the victim may notice a general degradation of the
> network, but is unlike to seek help.
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 28 Sep 2020 01:48:09 -0300

> I have stated in the Introduction that RA MITM is solved by RA-Guard (RFC 6105). I have put RA out of the scope. I do not know how to do it better.

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.

> If one perimeter is broken - no possibility to create additional challenge for Intruder.

That is indeed the threat model for Neighbor Discovery.

> It is radical difference from IPv4 where L2 device could help by DHCP snooping and ARP filtering. IPv6 has additional security hole here.

IPv4 and IPv6 are essentially the same, modulo:

* for address resolution, the IPv6 traffic may be more complex, and 
hence monitoring and mitigations may be challenging (see RFC7113, and 
RFC6980)

* when it comes to automatic configuration, since SLAAC is push/pull (as 
opposed to just pull), hosts remain open to subsequent messages from 
local routers, and hence are "open to attack"

Other than that, you have the same possible issues, and the same kind of 
mitigations for both ipv4 and ipv6.

> It looks like I have patched it.

I wouldn't refer to this kind of attack as information leakage. 
Information leakage is when a party discloses information it is not 
meant to disclose.

Here, there's no information leakage taken place, but rather there's a 
protocol (ND) susceptible to impersonation attacks -- which shouldn't be 
a surprise, because ND does nothing to prevent that (hence the 
specification of SEND).

> If router would be compromised, then even encryption would not help, never to say RA-Guard. 

It's the attacker -- as opposed to the router -- that would send the 
redirect ;-)

> Does not matter how utterly "untrusted ND mode" would be chosen.

Not sure what you mean...

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 28 Sep 2020 10:13:56 +0000

Hi 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.
I agree that SAVI deep assistance from L2 could be an alternative to what I am proposing in the draft. But
- it is very complicated and expensive on switches, available only on small portion of vendors
- it is better to fix L3 problem at L3 (if possible - I do not know how to fix RA MITM without simple filtering on switch)
- 1st could be intruder, then SAVI would not block MITM: all users (from other subnets) would contact server and show credentials to intruder

I do not agree that IPv4 and IPv6 are equal on ND/ARP security.
IPv4 has DHCP - it is possible to snoop all messages and do filtering on the switch. It is simple and widely supported by switches.
IPv6 has no centralized authority to snoop, solution should be much more complex like SAVI. Hence, it is not widely supported by switch vendors.
Reference to "Trusted model" does not explain anything. Because this RFC has forgotten to document all attack vectors discussed in my current draft.

Any MITM is the leakage if information, because man-in-the-middle is capable to record and even change it.

I do reference in the draft that encrypted authentication is the solution that supersede this draft by security protection.
Just one problem: it has been refused by the market.

Eduard
> From: Fernando Gont [mailto:[email-masked]]
> Sent: 28 сентября 2020 г. 7:48
> To: Vasilenko Eduard <[email-masked]>; Fernando Gont
> <[email-masked]>; [email-masked]
> > I have stated in the Introduction that RA MITM is solved by RA-Guard (RFC
> 6105). I have put RA out of the scope. I do not know how to do it better.
> 
> 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 am trying to fix only MITM from NA. Currently, it is easy to MITM any host on
> the link if any other host is compromised by different vulnerability.
> > It is radical difference from IPv4 where L2 device could help by DHCP snooping
> and ARP filtering. IPv6 has additional security hole here.
> 
> > If you believe that information leakage could be left intact just because "ND is
> for trusted model only" - it is you opinion, well respected here.
> 
> > Encrypted authentication has been rejected by the market. We are living in
> "ND is trusted model only" - it is all what we have.
> >
> > About redirect:

---

From: Fernando Gont <[email-masked]>
Date: Mon, 28 Sep 2020 08:03:26 -0300

Hello, Eduard,

> 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

> - 1st could be intruder, then SAVI would not block MITM: all users (from other subnets) would contact server and show credentials to intruder

The point is that you simply can't address all ND-based MITM vectors -- 
basically because ND has been designed with the premise that you trust 
your neighbors.

Additionally, if you require layer-2 cooperation to address some of 
them, I'm not sure why you'd not require cooperation to address all of them.

> IPv6 has no centralized authority to snoop, solution should be much more complex like SAVI. Hence, it is not widely supported by switch vendors.

Not sure what you mean: DHCP snooping is the equivalent of RA-guard. 
FHS is the equivalent of ARP policing.

> Reference to "Trusted model" does not explain anything. Because this RFC has forgotten to document all attack vectors discussed in my current draft.

Please see draft-ietf-opsec-nd-security.

> Any MITM is the leakage if information, because man-in-the-middle is capable to record and even change it.

MITM does not necesarily imply information leakage.

> Just one problem: it has been refused by the market.

Indeed.

However, you wither trust your neighbors, or you don't.

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 28 Sep 2020 11:27:18 +0000

Fernando,
> The point is that you simply can't address all ND-based MITM vectors -- basically
> because ND has been designed with the premise that you trust your neighbors.
Read the draft. I believe that rogue NA is blocked.

> Additionally, if you require layer-2 cooperation to address some of them, I'm not
> sure why you'd not require cooperation to address all of them.
No need for L2 cooperation for MITM based on rogue NA - it is solved just on ND level by current draft.

> Not sure what you mean: DHCP snooping is the equivalent of RA-guard.
No.
DHCP snooping creates ARP filtering table dynamically (for all ports).
RA-guard is static filter (router ports are at the stable location). RA-guard is very simple and easy to implement.

> Please see draft-ietf-opsec-nd-security.
OK. later

> However, you wither trust your neighbors, or you don't.
The life is in general not always black and white. Some things are more complicated (like distributed ND) - other possibilities exist.

Ed/
> Sent: 28 сентября 2020 г. 14:03
> >> 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.
> https://www.cisco.com/c/en/us/td/docs/ios-
> xml/ios/ipv6_fhsec/configuration/15-sy/ip6-nd-inspect.html
> 
> 
> 
> > - it is better to fix L3 problem at L3 (if possible - I do not know
> > how to fix RA MITM without simple filtering on switch)
> > - 1st could be intruder, then SAVI would not block MITM: all users
> > (from other subnets) would contact server and show credentials to
> > intruder
> 
> The point is that you simply can't address all ND-based MITM vectors -- basically
> because ND has been designed with the premise that you trust your neighbors.
> 
> Additionally, if you require layer-2 cooperation to address some of them, I'm not
> sure why you'd not require cooperation to address all of them.
> 
> 
> 
> > IPv4 has DHCP - it is possible to snoop all messages and do filtering on the
> switch. It is simple and widely supported by switches.
> > IPv6 has no centralized authority to snoop, solution should be much more
> complex like SAVI. Hence, it is not widely supported by switch vendors.
> 
> > Reference to "Trusted model" does not explain anything. Because this RFC has
> forgotten to document all attack vectors discussed in my current draft.
> 
> > I do reference in the draft that encrypted authentication is the solution that
> supersede this draft by security protection.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 28 Sep 2020 15:21:22 +0000

Hi Fernando,
I have looked carefully into draft-ietf-opsec-ipv6-nd-security-00

It has small section 6.1.1 that is related to discussed topic (half a page).
It does not discuss in details attack vectors. It does not mention information leakage.
It proposes only one solution that is not compatible to "unsolicited NA" (not to permit to change MAC till reachability would expire) - it would break any clustering technology. It would not prevent MITM when server would go to reload.

You do use term "hijack" in this document for the leakage of information.
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).
MITM is to be proxy during session initiation, when key/certificates should be accepted - it is still very possible to have MITM, many corporate resources are not properly connected to certification authorities. User would accept whatever pop up window with request "do you trust this key?".

Small section 6.3.1 is about MITM based on rogue NA  (half a page).
It does not discuss details. It does not propose any solution.
No reference that L2 switch is responsible for the solution of this problem.

That's it.
My draft discusses the problem of "rogue NA" much deeper (20x) and proposes solution on ND level.

Eduard
> From: Vasilenko Eduard
> Sent: 28 сентября 2020 г. 14:28
> To: 'Fernando Gont' <[email-masked]>; Fernando Gont
> > The point is that you simply can't address all ND-based MITM vectors
> > -- basically because ND has been designed with the premise that you trust your
> neighbors.
> The life is in general not always black and white. Some things are more
> complicated (like distributed ND) - other possibilities exist.
> 
> Ed/
> > > I have not understood what you mean by "First Hop Security"/ND
> > > inspection" -
> > it looks as very general term.
> >
> > See e.g.:
> > The point is that you simply can't address all ND-based MITM vectors
> > -- basically because ND has been designed with the premise that you trust your
> neighbors.
> >
> > > Any MITM is the leakage if information, because man-in-the-middle is
> > > capable
> > to record and even change it.
> >

---

From: Philip Homburg <[email-masked]>
Date: Tue, 29 Sep 2020 12:51:10 +0200

> I have 1 extra point: ND protocol is more vulnerable than former
> ARP, Because it was possible to effectively assist to ARP from L2:
> snoop DHCP and filter ARPs.  It is not possible on ND because
> architecture is distributed.  Read 1st attack vector - how easy it
> is now. No any help from L2 is possible.  With this draft IPv6
> security would get to the equal level with IPv4 on this aspect
> (ND/ARP).

What was introduced in the past (RA-guard) and the ARP filtering you just
described works at L2, and that is where it should be. It is necessary to
filter at individual switch ports.

You are trying to introduce filtering at L3 where is at ineffective because the
filtering at L2 is missing.

The net effect is that your proposal make ND more complex, which leads to
more bugs (including security bugs), make it harder to understand which 
makes it harder to diagnose issues.

This is a price to pay, but for more than 99% of the networks your changes
don't give any security benefit because the L2 filtering component is missing.

Note that IPv6 has a direct equivalent of the ARP filtering: snoop DHCPv6 IA_NA
and then lock ND based on the DHCP lease. This can be implement without
any protocol changes. It is just a matter of using DHCP instead of SLAAC.

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 30 Sep 2020 10:28:16 +0000

Hi Philip,
I agree that if IPv6 does not use SLAAC (use DHCP instead) then situation is equal (and overall not difficult) to assist from L2 to L3 security.

But if we would assume SLAAC case when help from switch is very difficult (SAVI has solved this problem with even more complexity that this draft).
Because for any filtering we need some table/rules.
This table is extremely simple and static for RA-guard (routers port is permanently connected to particular switch ports).
This table is dynamic, but could be easily snooped for any DHCP (IPv4 or IPv6).
There is not any one legitimate source to snoop in dynamic and distributed SLAAC (nothing like DHCP server or DHCP relay) - hence extreme complexity to assist to SLAAC from switch level. Hence, the problem is not properly resolved by the industry.

Eduard
> Sent: 29 сентября 2020 г. 13:51
> To: [email-masked]
> > Because it was possible to effectively assist to ARP from L2:
> > architecture is distributed.  Read 1st attack vector - how easy it is
> > now. No any help from L2 is possible.  With this draft IPv6 security
> > would get to the equal level with IPv4 on this aspect (ND/ARP).
> 
> described works at L2, and that is where it should be. It is necessary to filter at
> individual switch ports.
> 
> more bugs (including security bugs), make it harder to understand which makes it
> harder to diagnose issues.
> 
> This is a price to pay, but for more than 99% of the networks your changes don't
> give any security benefit because the L2 filtering component is missing.
> 
> and then lock ND based on the DHCP lease. This can be implement without any
> protocol changes. It is just a matter of using DHCP instead of SLAAC.
>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 30 Sep 2020 12:53:48 +0200

> I agree that
> if IPv6 does not use SLAAC (use DHCP instead) then situation is
> equal (and overall not difficult) to assist from L2 to L3 security.
> 
> But if we would assume SLAAC case when help from switch is very
> difficult (SAVI has solved this problem with even more complexity
> that this draft).  Because for any filtering we need some table/rules.
> This table is extremely simple and static for RA-guard (routers
> port is permanently connected to particular switch ports).  This
> table is dynamic, but could be easily snooped for any DHCP (IPv4
> or IPv6).  There is not any one legitimate source to snoop in
> dynamic and distributed SLAAC (nothing like DHCP server or DHCP
> relay) - hence extreme complexity to assist to SLAAC from switch
> level. Hence, the problem is not properly resolved by the industry.

So, the obvious thing to do is make sure it works for DHCPv6 and then inform
people of the difference in security between DHCPv6 and SLAAC.

Though I'm not sure if ARP filtering can also do MAC filtering, i.e. what
happens if I make a DHCP request with a MAC address that belongs to another
host?

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 30 Sep 2020 13:32:57 +0000

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.
Major vendors support DHCPv6 snooping (then could filter ND NA):
https://support.huawei.com/enterprise/en/doc/EDOC1000141942/fd2f4475/configuring-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".

About draft complexity:
3 basic principles are very simple to understand (end of introduction section). Hence, it should be simple to troubleshoot and operate.
But I do agree that details are complex for how to implement these basic principles into different sections of ND. Somebody should really strain his brain to check me and XiPeng - we had a lot of discussions.
It is normal and expected for ND. Because ND is distributed. Hence, many things in ND are complex.

Eduard
> Sent: 30 сентября 2020 г. 13:54
> To: [email-masked]
> > if IPv6 does not use SLAAC (use DHCP instead) then situation is equal
> > (and overall not difficult) to assist from L2 to L3 security.
> >
> > difficult (SAVI has solved this problem with even more complexity that
> > this draft).  Because for any filtering we need some table/rules.
> > This table is extremely simple and static for RA-guard (routers port
> > is permanently connected to particular switch ports).  This table is
> > dynamic, but could be easily snooped for any DHCP (IPv4 or IPv6).
> > There is not any one legitimate source to snoop in dynamic and
> > distributed SLAAC (nothing like DHCP server or DHCP
> Though I'm not sure if ARP filtering can also do MAC filtering, i.e. what happens
> if I make a DHCP request with a MAC address that belongs to another host?
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 30 Sep 2020 13:44:50 +0000

I have forgotten to mention that this draft would protect against leakage of information in DHCP, SLAAC, or mixed environment.
DHCP snooping would be not needed.
But I do not want to compete against DHCP snooping - because it is really simple.

> Sent: 30 сентября 2020 г. 16:34
> To: 'Philip Homburg' <[email-masked]>; [email-masked]
> 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.
> 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.
> 3 basic principles are very simple to understand (end of introduction section).
> Hence, it should be simple to troubleshoot and operate.
> But I do agree that details are complex for how to implement these basic
> principles into different sections of ND. Somebody should really strain his brain
> to check me and XiPeng - we had a lot of discussions.
> > So, the obvious thing to do is make sure it works for DHCPv6 and then
> > inform people of the difference in security between DHCPv6 and SLAAC.
> >
> > Though I'm not sure if ARP filtering can also do MAC filtering, i.e.
> > what happens if I make a DHCP request with a MAC address that belongs to
> another host?
> >

---

From: Fernando Gont <[email-masked]>
Date: Wed, 30 Sep 2020 16:25:38 -0300

> 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 j…

DHCPv6 snooping is not necessarily trivial (see RFC7610). Similarly, the 
way most vendors implement RA-Guard, is trivially evasible (see RFC7113).

> 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,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 30 Sep 2020 16:31:12 -0300

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,