Subject: New draft-vasilenko-6man-nd-mitm-protection - trust model

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 17 Nov 2020 11:00:52 +0000

Hi Fernando,
I do agree that "trusting on the link" (i.e. "digital signature") is the best solution.
But because industry has rejected the hassle with certification authority,
We have nothing to discuss here.

The security hole that I have presented today
Is very easy to attack.
Something should be done about it.
Unfortunately, it is not encryption.
Eduard

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Nov 2020 13:30:08 +0000

Hello Eduard

This and many other issues with reactive ND such as address scanning DOS attacks are well known. Patching one of these many holes may add more complexity than benefits, and creates its own side effects.

There are environments where a node does not care, such as a coffee shop. Better use a VPN and form a new address if one doesn’t work. If that still fails go to another coffee shop.

Then there’s the semi protected domain, like home or traditional SoHo. So far the problem was avoided by access control, e.g., using physical access or WPA2 in an attempt to make sure that only trusted nodes would join the network. In the walled garden, nobody does anything wrong so there’s no need for police.

Certainly this peace and love approach can only be taken so far and environments such as corporate networks already require a better security. Home may follow as more and more devices are connected.

The link access control is being tightened with technologies like MACSEC and 1x; but we all know that depending only on the link access control is not enough, and we need at some point to introduce zero trust; in other words, we must deploy some police to enforce the proper use of addresses and services in the network.

My view is that defining that police would be a better use of our time than patching Swiss cheese.

Regards,

Pascal

> Le 17 nov. 2020 à 12:01, Vasilenko Eduard <[email-masked]> a écrit :
> 
> Hi Fernando,
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 17 Nov 2020 14:19:34 +0000

Hi Pascal,
I have not understood who is police in your example.
If you mean that Enterprise should prevent initial penetration of Intruder to the link, or else whole server segment is compromised (all information from all applications are liked, including credentials).
Then it is not the way how security is done. Security is "the many layers that Intruder should penetrate".

Complains about ND security are small because small list of Enterprises adopted IPv6 yet. IPv6 is primarily for Internet services yet.

In the absence of GRAND: router should ask for binding by multicast NS anyway. No any additional requests on the wire by this draft.
Is it complexity?
In the presence of GRAND: 1 excessive multicast NS. Is it the big payment for leakage of information?

This draft is effectively the proposition to correlate NA with NS. If more then 1:1 - then alarm.
And what should be done after alarm is discussable.

Eduard
> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: 17 ноября 2020 г. 16:30
> To: Vasilenko Eduard <[email-masked]>
> Cc: Fernando Gont <[email-masked]>; 6man WG <[email-masked]>
> Subject: Re: New draft-vasilenko-6man-nd-mitm-protection - trust model
> 
> Hello Eduard
> 
> This and many other issues with reactive ND such as address scanning DOS
> attacks are well known. Patching one of these many holes may add more
> complexity than benefits, and creates its own side effects.
> 
> There are environments where a node does not care, such as a coffee shop.
> Better use a VPN and form a new address if one doesn’t work. If that still fails go
> to another coffee shop.
> 
> Then there’s the semi protected domain, like home or traditional SoHo. So far
> the problem was avoided by access control, e.g., using physical access or WPA2
> in an attempt to make sure that only trusted nodes would join the network. In
> the walled garden, nobody does anything wrong so there’s no need for police.
> 
> Certainly this peace and love approach can only be taken so far and
> environments such as corporate networks already require a better security.
> Home may follow as more and more devices are connected.
> 
> The link access control is being tightened with technologies like MACSEC and 1x;
> but we all know that depending only on the link access control is not enough,
> and we need at some point to introduce zero trust; in other words, we must
> deploy some police to enforce the proper use of addresses and services in the
> network.
> 
> > But because industry has rejected the hassle with certification
> > authority, We have nothing to discuss here.
> >
> > The security hole that I have presented today Is very easy to attack.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 Nov 2020 16:08:30 +0100

> Then it is not
> the way how security is done. Security is "the many layers that
> Intruder should penetrate".

I don't like this approach at all. ND is fundamental to IPv6. We should
be very careful making changes to ND. Making changes that break things
("Link Layer Address rewrite or initial write for any Neighbor Cache entry
MUST be the result of only *multicast* Neighbor Solicitation.") need
very strong justification. In my opinion the marginal effect this draft has
on security is not worth it.

However, upon reflection there also seems to be a fundamental flaw in how this
draft works.

The key idea of this draft is the following:
"Link Layer Address rewrite or initial write for any Neighbor
"Cache entry MUST be the result of only *multicast* Neighbor
"Solicitation. Multicast would give a chance for Poisoned Victim
"to understand that many nodes are going to use the same IP
"address.

So an attacker A wants to update the neighbor cache entry for victim V on
router R with MAC address of the atacker MAC_A.

Today the attacker can send a point-to-point NS with source V and destination
R and source link-layer address option with value MAC_A.

The proposal is to force the attacker to send a multicast NS. Then, the
idea is that the victim will also see this multicast and can generate an
alert.

This is what RFC 4861 (ND) says about multicast:
"the solicited-node multicast address corresponding to the target address"
(Section 4.3). 

This multicast address is defined in RFC 4291 (IP Version 6 Addressing
Architecture) as:
"Solicited-Node multicast address are computed as a function of a
"node's unicast and anycast addresses.  A Solicited-Node multicast
"address is formed by taking the low-order 24 bits of an address
"(unicast or anycast) and appending those bits to the prefix
"FF02:0:0:0:0:1:FF00::/104
(Section 2.7.1)

Section 7.2.1. of RFC 4861 has this:
"When a multicast-capable interface becomes enabled, the node MUST
"join the all-nodes multicast address on that interface, as well as
"the solicited-node multicast address corresponding to each of the IP
"addresses assigned to the interface.

So the victim host does not listen to the solicited-node multicast address
of the NS, because that packet goes to the router. So the victim will never
know, unless the victim does not do multicast filtering (and neither does
the network).

This proposal also requires interesting layering violations to implement
correctly, but I'll leave that for another discussion.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Nov 2020 15:11:01 +0000

Hello Eduard

> I have not understood who is police in your example.

The police has to be enforced by routers or first hop L3 switches and APs. Direct host to host was tried with SEND and that was a failure.

> If you mean that Enterprise should prevent initial penetration of Intruder to the link, or else whole server segment is compromised (all information from all applications are liked, including crede…

The point I was making is that hosts may be compromised to misuse their access to the link. So link access control cannot be good enough; and then there’s the ND DOS attacks that do not even need link access.

For remote dos attacks the attacker pings addresses that do not exist and causes broadcast at the scale of the L2 fabric. The police function at the link ingress router must be aware of the valid addresses in the network and drop packets for addresses that do not exist, it must do that at silicon speed.

For IP address spoofing and impersonation, the attacker must be on link, e.g. in a compromised host. The police must be able to validate that a host that sources packets with an IP address or sends ND messages claiming an IP address, owns that address. The police function at the access switch/router must be aware of the binding of IP and MAC and preferably be able to revalidate a proof of ownership for both at any time. It must know that ahead of time.

Cheers,

Pascal

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 17 Nov 2020 15:27:35 +0000

Hi Philip,
It is not possible to force Intruder to do anything. Intruder could send unicast NS with any possible flag set. He is intruder - definitely out of any IETF restrictions.
You have misunderstood proposal.

Intruder is trying to poison cache on the router. Rewrite (or initial write) of MAC should happen on the router.
Hence, router should sent multicast NS to give chance for victim to reply, then router would see duplicity.

By the way, in the absence of GRAND, Router would send multicast NS anyway (after traffic would return from the Internet).
Additional functionality is just count how many NA responses would be received.

Hence, your excepts from ND and IP addressing RFCs are not relevant - I do not propose to change anything in the way how NS/NA should be done.
I propose to just count number of NAs after multicast NS.
And additionally (in GRAND environment) to generate multicast NS (where before was possible to check reachability by unicast NS).

Eduard
> From: [email-masked] [mailto:pch-b9D3CB0F5@u-
> 1.phicoh.com] On Behalf Of Philip Homburg
> Sent: 17 ноября 2020 г. 18:09
> To: [email-masked]
> Cc: Vasilenko Eduard <[email-masked]>
> I don't like this approach at all. ND is fundamental to IPv6. We should be very
> careful making changes to ND. Making changes that break things ("Link Layer
> Address rewrite or initial write for any Neighbor Cache entry MUST be the result
> of only *multicast* Neighbor Solicitation.") need very strong justification. In my
> opinion the marginal effect this draft has on security is not worth it.
> 
> "Link Layer Address rewrite or initial write for any Neighbor "Cache entry MUST
> be the result of only *multicast* Neighbor "Solicitation. Multicast would give a
> chance for Poisoned Victim "to understand that many nodes are going to use the
> same IP "address.
> 
> Today the attacker can send a point-to-point NS with source V and destination R
> and source link-layer address option with value MAC_A.
> 
> The proposal is to force the attacker to send a multicast NS. Then, the idea is
> that the victim will also see this multicast and can generate an alert.
> 
> "Solicited-Node multicast address are computed as a function of a "node's
> unicast and anycast addresses.  A Solicited-Node multicast "address is formed by
> taking the low-order 24 bits of an address "(unicast or anycast) and appending
> those bits to the prefix
> "When a multicast-capable interface becomes enabled, the node MUST "join the
> all-nodes multicast address on that interface, as well as "the solicited-node
> multicast address corresponding to each of the IP "addresses assigned to the
> interface.
> 
> So the victim host does not listen to the solicited-node multicast address of the
> NS, because that packet goes to the router. So the victim will never know, unless
> the victim does not do multicast filtering (and neither does the network).
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 17 Nov 2020 15:44:12 +0000

Hi Pascal,
Looking to your explanation who is police - I see that it could be only SAVI. But:
- it has not become popular on the market (just couple of products support it)
- it does not solve the problem for server segment, because IP address could be hijacked while server/VM is in reboot
I am not aware about any other "police" functionality on "routers or first hop L3 switches and APs" that could help against these attack vectors.

I completely agree about you general statement that principally different ND is better.
I personally believe that draft-chakrabarti-nordmark-energy-aware-nd was the best approach.
Your WiND is >50% based on it, just no multi-link complexity in chakrabarti-nordmark draft.
IMHO: Multi-link is not the mandatory part of address resolution - it should be kept as the separate specification.
But it does not make sense to discuss it: It needs host change - it has been rejected by 6man.

Eduard
> Sent: 17 ноября 2020 г. 18:11
> The police has to be enforced by routers or first hop L3 switches and APs. Direct
> host to host was tried with SEND and that was a failure.
> 
> > If you mean that Enterprise should prevent initial penetration of Intruder to
> the link, or else whole server segment is compromised (all information from all
> applications are liked, including credentials).
> 
> The point I was making is that hosts may be compromised to misuse their access
> to the link. So link access control cannot be good enough; and then there’s the
> ND DOS attacks that do not even need link access.
> 
> For remote dos attacks the attacker pings addresses that do not exist and causes
> broadcast at the scale of the L2 fabric. The police function at the link ingress
> router must be aware of the valid addresses in the network and drop packets for
> addresses that do not exist, it must do that at silicon speed.
> 
> For IP address spoofing and impersonation, the attacker must be on link, e.g. in
> a compromised host. The police must be able to validate that a host that
> sources packets with an IP address or sends ND messages claiming an IP
> address, owns that address. The police function at the access switch/router
> must be aware of the binding of IP and MAC and preferably be able to revalidate
> a proof of ownership for both at any time. It must know that ahead of time.
> 
> Cheers,
> 
> Pascal
> 
> > Complains about ND security are small because small list of Enterprises
> adopted IPv6 yet. IPv6 is primarily for Internet services yet.
> >
> > In the absence of GRAND: router should ask for binding by multicast NS
> anyway. No any additional requests on the wire by this draft.
> > Is it complexity?
> >> This and many other issues with reactive ND such as address scanning
> >> DOS attacks are well known. Patching one of these many holes may add
> >> more complexity than benefits, and creates its own side effects.
> >>
> >> Better use a VPN and form a new address if one doesn’t work. If that
> >> still fails go to another coffee shop.
> >>
> >> Then there’s the semi protected domain, like home or traditional
> >> SoHo. So far the problem was avoided by access control, e.g., using
> >> physical access or WPA2 in an attempt to make sure that only trusted
> >> nodes would join the network. In the walled garden, nobody does anything
> wrong so there’s no need for police.
> >>
> >> The link access control is being tightened with technologies like
> >> MACSEC and 1x; but we all know that depending only on the link access
> >> control is not enough, and we need at some point to introduce zero
> >> trust; in other words, we must deploy some police to enforce the
> >> proper use of addresses and services in the network.
> >>
> >>> Le 17 nov. 2020 à 12:01, Vasilenko Eduard
> >>> <[email-masked]> a
> >> écrit :
> >>>
> >>> Hi Fernando,
> >>> I do agree that "trusting on the link" (i.e. "digital signature") is
> >>> the best
> >> solution.
> >>> IETF IPv6 working group mailing list [email-masked] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Nov 2020 15:55:26 +0000

> I personally believe that draft-chakrabarti-nordmark-energy-aware-nd was the best approach.

It became RFC 8505; sad that you prefer the draft over the RFC. A technical justification for that preference ?

> But it does not make sense to discuss it: It needs host change - it has been rejected by 6man.

An interesting claim; I missed that when that happened, please provide a link. 

Cheers 

Pascal

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 Nov 2020 17:11:00 +0100

> Hi Philip, It is not
> possible to force Intruder to do anything. Intruder could send
> unicast NS with any possible flag set. He is intruder - definitely
> out of any IETF restrictions.  You have misunderstood proposal.
> 
> Intruder is trying to poison cache on the router. Rewrite (or
> initial write) of MAC should happen on the router.  Hence, router
> should sent multicast NS to give chance for victim to reply, then
> router would see duplicity.

You are correct. I got it wrong. Which strengthens my opinion that the 
draft makes changes that are too complex for the rather small security
benefits it provides.

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 17 Nov 2020 16:14:54 +0000

Hi Pascal,
RFC 8505 is not the product of 6man. RFC 8505 is the mix of "draft-chakrabarti-nordmark-energy-aware-nd" and multi-link developed by you.
I still see attempts to develop multi-link by OMNI. Hence, in general, multi-link is needed and valuable thing. Just it should be optional (separate specification).

The fact that draft-chakrabarti-nordmark-energy-aware-nd has expired on September 2012 is easy to check.
Eduard
> Sent: 17 ноября 2020 г. 18:55
> > - it does not solve the problem for server segment, because IP address
> > could be hijacked while server/VM is in reboot I am not aware about any other
> "police" functionality on "routers or first hop L3 switches and APs" that could
> help against these attack vectors.
> >
> >> The police has to be enforced by routers or first hop L3 switches and
> >> APs. Direct host to host was tried with SEND and that was a failure.
> >>
> >> the link, or else whole server segment is compromised (all
> >> information from all applications are liked, including credentials).
> >>
> >> The point I was making is that hosts may be compromised to misuse
> >> their access to the link. So link access control cannot be good
> >> enough; and then there’s the ND DOS attacks that do not even need link
> access.
> >>
> >> For remote dos attacks the attacker pings addresses that do not exist
> >> and causes broadcast at the scale of the L2 fabric. The police
> >> function at the link ingress router must be aware of the valid
> >> addresses in the network and drop packets for addresses that do not exist, it
> must do that at silicon speed.
> >>
> >> For IP address spoofing and impersonation, the attacker must be on
> >> link, e.g. in a compromised host. The police must be able to validate
> >> that a host that sources packets with an IP address or sends ND
> >> messages claiming an IP address, owns that address. The police
> >> function at the access switch/router must be aware of the binding of
> >> IP and MAC and preferably be able to revalidate a proof of ownership for
> both at any time. It must know that ahead of time.
> >>
> >> Cheers,
> >>
> >> Pascal
> >>
> >>> Then it is not the way how security is done. Security is "the many
> >>> layers that
> >>> In the presence of GRAND: 1 excessive multicast NS. Is it the big
> >>> payment for
> >> leakage of information?
> >>>
> >>> This draft is effectively the proposition to correlate NA with NS.
> >>> If more then
> >> 1:1 - then alarm.
> >>>> This and many other issues with reactive ND such as address
> >>>> scanning DOS attacks are well known. Patching one of these many
> >>>> holes may add more complexity than benefits, and creates its own side
> effects.
> >>>>
> >>>> Better use a VPN and form a new address if one doesn’t work. If
> >>>> that still fails go to another coffee shop.
> >>>>
> >>>> physical access or WPA2 in an attempt to make sure that only
> >>>> trusted nodes would join the network. In the walled garden, nobody
> >>>> does anything
> >>>> MACSEC and 1x; but we all know that depending only on the link
> >>>> access control is not enough, and we need at some point to
> >>>> introduce zero trust; in other words, we must deploy some police to
> >>>> enforce the proper use of addresses and services in the network.
> >>>>
> >>>>> I do agree that "trusting on the link" (i.e. "digital signature")
> >>>>> is the best
> >>>> solution.
> >>>>> ------------------------------------------------------------------
> >>>>> -- IETF IPv6 working group mailing list [email-masked]
> >>>>> Administrative

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 17 Nov 2020 16:17:13 +0000

> Which strengthens my opinion that the draft
> makes changes that are too complex for the rather small security benefits it
> provides.
[Ed: ] What is too complex?
Count the number of NA responses to the single NS?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Nov 2020 17:22:48 +0000

Hello Eduard

> RFC 8505 is not the product of 6man. RFC 8505 is the mix of "draft-
> chakrabarti-nordmark-energy-aware-nd" and multi-link developed by you.

The registration is the same when done over ethernet or Wi-Fi, so your words do not resonate. 
What changed is the management of mobility and the simplification of link local processing. 

> I still see attempts to develop multi-link by OMNI. Hence, in general, multi-link
> is needed and valuable thing. Just it should be optional (separate specification).

The multilink complexity that I can think of is the ND proxy. It was effectively split and that split was made in flight while writing RFC 6775, if you care for the real history.
If there's something wrong with RFC 8505 please let us know. 

> September 2012 is easy to check.

That's very different from rejected and that's not WiND. We needed to progress and we did it at 6lo where it was more constructive.
You're making your conclusions and then spreading them as ground truth. Please use words more carefully.
Yes, I want to get WiND generalized, but people need to understand why first. The discussions on P2P and on ND security are getting us right there.

Note also that pretty much all the drafts we see at 6MAN including yours ask for a change in the host. 

Cheers,

Pascal

> > > - it does not solve the problem for server segment, because IP
> > > address could be hijacked while server/VM is in reboot I am not
> > > aware about any other
> > "police" functionality on "routers or first hop L3 switches and APs"
> > that could help against these attack vectors.
> > >
> > > I completely agree about you general statement that principally
> > > different ND is
> > better.
> > > I personally believe that draft-chakrabarti-nordmark-energy-aware-nd
> > > was the
> > best approach.
> >
> > It became RFC 8505; sad that you prefer the draft over the RFC. A
> > technical justification for that preference ?
> >
> > > Your WiND is >50% based on it, just no multi-link complexity in
> > > chakrabarti-
> > nordmark draft.
> > > IMHO: Multi-link is not the mandatory part of address resolution -
> > > it should be
> > kept as the separate specification.
> > > But it does not make sense to discuss it: It needs host change - it
> > > has been
> > rejected by 6man.
> >
> > >> The police has to be enforced by routers or first hop L3 switches
> > >> and APs. Direct host to host was tried with SEND and that was a failure.
> > >>
> > >> For remote dos attacks the attacker pings addresses that do not
> > >> exist and causes broadcast at the scale of the L2 fabric. The
> > >> police function at the link ingress router must be aware of the
> > >> valid addresses in the network and drop packets for addresses that
> > >> do not exist, it
> > >> link, e.g. in a compromised host. The police must be able to
> > >> validate that a host that sources packets with an IP address or
> > >> sends ND messages claiming an IP address, owns that address. The
> > >> police function at the access switch/router must be aware of the
> > >> binding of IP and MAC and preferably be able to revalidate a proof
> > >> of ownership for
> > >>>> There are environments where a node does not care, such as a
> > >>>> coffee
> > shop.
> > >>>> SoHo. So far the problem was avoided by access control, e.g.,
> > >>>> using physical access or WPA2 in an attempt to make sure that
> > >>>> only trusted nodes would join the network. In the walled garden,
> > >>>> nobody does anything
> > >>>> Certainly this peace and love approach can only be taken so far
> > >>>> and environments such as corporate networks already require a better
> security.
> > >>>> introduce zero trust; in other words, we must deploy some police
> > >>>> to enforce the proper use of addresses and services in the network.
> > >>>>
> > >>>>> I do agree that "trusting on the link" (i.e. "digital
> > >>>>> signature") is the best
> > >>>> solution.
> > >>>>> --
> > >>> --

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Nov 2020 11:51:12 -0300

Hi, Eduard,

FWIW, I have *not* argued that trusting the link is a good idea. I've 
just noted that trusting the  link is a basic assumption for ND operation.

As such, I find it hard to believe that you (or this group) would be 
able to come up with something that can mitigate ND attacks, without any 
significant side effect. And when I say "ND", I do mean everything that 
ND involves, including mechanisms based on: NS, NA, RS, RA, and Redirects.

Each and all of them allow for both MITM and DoS attacks.

The basic problem here is that ND messages are not authenticated, and we 
do not only employ ND with a pull model, but also with a push model. So 
modulo something like "do FCFS", "don't change information if it looks 
like it's working", I don't think there's much you can do -- and that, 
of course, comes at the expense of reducing responsiveness (so it is a 
tradeoff that should be evaluated).

So my take is that the only way of preventing ND-bases MTIM attacks at 
the protocol level is essentially to employ operational mitigations such 
as separate nodes in different links, or enforcing a filtering policy 
(FHS, SAVI, RA-Guard, ND-inspection, etc).

Your document seems to try to tackle NA-based attacks -- but that's one 
message out of five.

As an attacker I don't care which specific vector I use, as long as it 
works. And may take is that the underlying issue is so inherent to ND 
(unauthenticated packets on a link that is implicitly trusted) that you 
want be able to address ND-based MITM/DoS attacks unless you replace ND 
with something else.

Now, I could certainly be wrong. So if you can address the rest of the 
possible vectors, I'd be glad to change my mind.

Thanks,
Fernando

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Nov 2020 12:00:44 -0300

On 17/11/20 10:30, Pascal Thubert (pthubert) wrote:
[...]
> My view is that defining that police would be a better use of our time than patching Swiss cheese.

I'd probably phrase it differently: If you need a flying vehicle, you 
probably need a plane (or a helicopter, for instance :-) ). If you try 
to make a car fly, most likely you'll realize that it won't, unless you 
have managed to convert it to something else that is no longer a car.

I am all for improvements. But in the case "attacks" there is *intent* 
involved. So picking one specific vector that might be easier to do 
something about, while leaving all other known vectors for "future work" 
doesn't seem a lot sensible to me.

IOW, I don't think you can even patch the swiss cheese, in this case. :-)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Nov 2020 12:07:38 -0300

Hi, Pascal,

On 17/11/20 12:11, Pascal Thubert (pthubert) wrote:
[...]
> addresses in the network and drop packets for addresses that do not
> exist, it must do that at silicon speed.

... or at the very lesast enforce limits on the NC size, and prioritize 
entries other than those in the INCOMPLETE state.

> IP and MAC and preferably be able to revalidate a proof of ownership
> for both at any time. It must know that ahead of time.

And this can be challenging, of course, particularly when hosts do not 
signal the network when an address is no longer used, or for how long it 
is expected to be used (until further notice). -- because the network 
police will eventually hit resource limits and hence have to forget 
about mappings. -- and even if it doesn't, it could well be the case 
that one specific address is reused by a different system at some other 
point in time (e.g. think RFC4941).

Thanks,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 18 Nov 2020 15:37:33 +0000

Hello Fernando

> ... or at the very lesast enforce limits on the NC size, and prioritize entries other
> than those in the INCOMPLETE state.

This is the minimum self-preservation, it goes (almost) without saying ; ) But this is not police. 
A real police should protect the network, and that includes preventing the first rogue broadcast.
Also as you know, saturating the ND cache is also an attack against the creation of new valid entries. 

> point in time (e.g. think RFC4941).

All true, this is really an issue with snooping addresses. 

All we can do there is challenge the address periodically, but that tends to keep the address alive longer in some scenarios, and doing that from a L2 box can be challenging.
Add to that the MAC privacy that may get increasingly aggressive.

Ideally, the host would declare the address with a lifetime associated that matches its intent for that address (short vs. long lived, mobile visitor of an SSID vs. long dweller in a corp or home network), and even better, cleanly remove the address when it can from ND and DHCP. 

Dunno if the hosts would do it if they could. But we are not giving them the means, so the responsibility is fully on our side at this point.
So there cannot be an official police. There are products doing snooping games, but that can only be taken so far as you point out.

Keep safe;

Pascal

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 18 Nov 2020 16:03:23 +0000

Hi Fernando,
I am not capable to better address the protection other messages (RA, RS, Redirect).
But why you (or anybody else) are not satisfied with RA-guard and RA-guard+?
It is easy for L2 device.

NA is very big security hole now: MITM is the leakage of information. Why not to address?
Full snooping of NS protocol with active solicitation in questionable situations on L2 device (SAVI) has not become popular. It is too much for L2 device.
What I am proposing is just to count number of NA responses to multicast NS and compare it to allowed level (typically 1).
Why you could not accept that it is the solution?

Why it is the principle problem for you that some messages would be protected by ND itself,
but other messages would be 100% filtered on L2 ports (without parsing the content)?

Eduard
> From: Fernando Gont [mailto:[email-masked]]
> Sent: 18 ноября 2020 г. 17:51
> To: Vasilenko Eduard <[email-masked]>; 6man WG
> <[email-masked]>
> FWIW, I have *not* argued that trusting the link is a good idea. I've just noted
> that trusting the  link is a basic assumption for ND operation.
> 
> As such, I find it hard to believe that you (or this group) would be able to come
> up with something that can mitigate ND attacks, without any significant side
> effect. And when I say "ND", I do mean everything that ND involves, including
> mechanisms based on: NS, NA, RS, RA, and Redirects.
> 
> The basic problem here is that ND messages are not authenticated, and we do
> not only employ ND with a pull model, but also with a push model. So modulo
> something like "do FCFS", "don't change information if it looks like it's working",
> I don't think there's much you can do -- and that, of course, comes at the
> expense of reducing responsiveness (so it is a tradeoff that should be evaluated).
> 
> 
> So my take is that the only way of preventing ND-bases MTIM attacks at the
> protocol level is essentially to employ operational mitigations such as separate
> nodes in different links, or enforcing a filtering policy (FHS, SAVI, RA-Guard, ND-
> inspection, etc).
> 
> As an attacker I don't care which specific vector I use, as long as it works. And
> may take is that the underlying issue is so inherent to ND (unauthenticated
> packets on a link that is implicitly trusted) that you want be able to address ND-
> based MITM/DoS attacks unless you replace ND with something else.
> 
> Now, I could certainly be wrong. So if you can address the rest of the possible
> vectors, I'd be glad to change my mind.
> 
> Thanks,
> Fernando
> 
> 
> 
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 18 Nov 2020 16:29:27 +0000

Hi Pascal,
You are right: RFC 6775 already has multi-link story. It is correctly to compare to it. I did not know that you do not include RFC 6775 into WiND - my fault. I did mean all series of ND standards developed by you.
RFC 6775 was develop by you with the same people (Chakrabarti, Nordmark). Hence, no surprise that it fully reuse "draft-chakrabarti-nordmark-energy-aware-nd".
But sorry I like original draft more, because it did not have complexity of multi-link and it did show migration path with mixed-mode link.
By the way, mixed mode link is really mandatory for universal solution.

I have not understood why you did mention Ethernet vs WiFi. I did understand that all these versions are acceptable for all type of L2 links.

IMHO: it is possible to split 8505 for 2 parts: simplified standard for 1 link and extensions for multi-link registration.
Then majority of installations (like CPE) would not need to implement second draft.
It is not enough to claim universal solution, because mixed mode is needed for migration.

Eduard
> Sent: 17 ноября 2020 г. 20:23
> Subject: RE: New draft-vasilenko-6man-nd-mitm-protection - trust model
> 
> Hello Eduard
> 
> > I still see attempts to develop multi-link by OMNI. Hence, in general,
> > multi-link is needed and valuable thing. Just it should be optional (separate
> specification).
> 
> The multilink complexity that I can think of is the ND proxy. It was effectively
> split and that split was made in flight while writing RFC 6775, if you care for the
> real history.
> That's very different from rejected and that's not WiND. We needed to progress
> and we did it at 6lo where it was more constructive.
> Yes, I want to get WiND generalized, but people need to understand why first.
> The discussions on P2P and on ND security are getting us right there.
> 
> > > > I personally believe that
> > > > draft-chakrabarti-nordmark-energy-aware-nd
> > > > was the
> > > best approach.
> > >
> > > > But it does not make sense to discuss it: It needs host change -
> > > > it has been
> > > rejected by 6man.
> > >
> > > >> valid addresses in the network and drop packets for addresses
> > > >> that do not exist, it
> > > >> For IP address spoofing and impersonation, the attacker must be
> > > >> on link, e.g. in a compromised host. The police must be able to
> > > >> binding of IP and MAC and preferably be able to revalidate a
> > > >> proof of ownership for
> > > >>> Then it is not the way how security is done. Security is "the
> > > >>> many layers that
> > > >>> In the presence of GRAND: 1 excessive multicast NS. Is it the
> > > >>> big payment for
> > > >> leakage of information?
> > > >>>
> > > >>>> Then there’s the semi protected domain, like home or
> > > >>>> traditional SoHo. So far the problem was avoided by access
> > > >>>> control, e.g., using physical access or WPA2 in an attempt to
> > > >>>> make sure that only trusted nodes would join the network. In
> > > >>>> The link access control is being tightened with technologies
> > > >>>> like MACSEC and 1x; but we all know that depending only on the
> > > >>>> link access control is not enough, and we need at some point to
> > > >>>> introduce zero trust; in other words, we must deploy some
> > > >>>> police to enforce the proper use of addresses and services in the
> network.
> > > >>>>
> > > >>>>> But because industry has rejected the hassle with
> > > >>>>> certification authority, We have nothing to discuss here.
> > > >>>>>
> > > >>>>> --------------------------------------------------------------
> > > >>>>> --
> > > >>>>> --
> > > >>>>> --------------------------------------------------------------
> > > >>>>> --
> > > >>>>> --
> > > >>>>> --

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Nov 2020 13:02:13 -0300

On 18/11/20 12:37, Pascal Thubert (pthubert) wrote:
> This is the minimum self-preservation, it goes (almost) without saying ; ) 

100% agreed :-) -- still, quite a lot of iplementations ahve failed to 
do this at least at some point.

[...]
> Ideally, the host would declare the address with a lifetime associated that matches its intent for that address (short vs. long lived, mobile visitor of an SSID vs. long dweller in a corp or home n…

Agreed. However, RFC4861 doesn't have such feature.

> Dunno if the hosts would do it if they could. But we are not giving them the means, so the responsibility is fully on our side at this point.

Agreed on this one, too.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Nov 2020 14:09:50 -0300

> It is easy for L2 device.

Because RA-Guard is an operational mitigation. that is enforced by the 
network. My expectation is that all issues of the same kind of a given 
protocol are solved at the same place.

Note: RA-guard mitigates RA-based attacks, not RS-based or 
Redirect-based attacks. For the later two you need ND inspection/FHS, at 
which point you'd also police NS/NA there, too.

> NA is very big security hole now:

If there is a proble, the problem is ND, not the specific case of 
NA-based attacks.

> MITM is the leakage of information.

No. MITM is not a leakage attack. Information may leak if the data flow 
is not protected. That's IP's (or an upper-layer's) business -- not ND's.

> Why not to address?

Back to my analogy: this is like arguing that a car cannot fly, and that 
wings need to be added.  -- and me asking if you also plan to add a 
propeller (and... and ...) because otherwise the car will still not fly.

Or, if you want it in a different way: "the security of a chain is that 
of the weakest link".

So if you "improve" the processing of a single ND message, you haven't 
really improved ND's security.

> Full snooping of NS protocol with active solicitation in questionable situations on L2 device (SAVI) has not become popular. It is too much for L2 device. > What I am proposing is just to count number of NA responses to 
multicast NS and compare it to allowed level (typically 1).
> Why you could not accept that it is the solution?

Back to my analogy: what's the goal? For the car to be able to fly, or 
for the car to incorporate wings?

> but other messages would be 100% filtered on L2 ports (without parsing the content)?

Because that is a mess, and because you fix the protocol, or you don't. 
If you just work on NA's, you still depend on L2 mitigations. So what's 
the point?

(and yes, you do need to parse the content of messages. Think about SLLO 
in NSes, for example).

Thanks,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 18 Nov 2020 17:15:29 +0000

Your history still does not relate back enough in time. But it does not matter; what matters is not spreading the idea that 6MAN has rejected WiND. Leave us a chance to present it first.

The registration started with https://tools.ietf.org/html/draft-shelby-6lowpan-nd-00, same usual suspects. We voted for that model for 6LoWPAN at IETF Dublin, mind you, that was around 2008. See slides 43- 45 of https://www.ietf.org/proceedings/72/slides/6lowpan-0.pdf, it already says a lot. The "white board" is now called a 6LBR and can be decoupled from the backbone router. And RFC 6775 is rightfully part of WiND since it is the base for RFC 8505. RFC 8928 and RFC 8929 should ship very soon to complete the 6lo phase of the story.

Soon we can discuss how WiND would play at 6MAN, vs. the need for an ND police, the desire for P2P links, Link Local range (think mDNS scope) and related broadcast domain control, sleeping nodes, wireless integration, overlays, L3 routing in DC, unicast lookups, subnet agility (decoupled from local link), to list a few nice things we've come to expect in a modern network. I guess it will take a problem statement / applicability etc... to start with.

Keep safe;

Pascal

> From: Vasilenko Eduard <[email-masked]>
> Sent: mercredi 18 novembre 2020 17:29
> To: Pascal Thubert (pthubert) <[email-masked]>
> You are right: RFC 6775 already has multi-link story. It is correctly to compare
> to it. I did not know that you do not include RFC 6775 into WiND - my fault. I
> did mean all series of ND standards developed by you.
> RFC 6775 was develop by you with the same people (Chakrabarti, Nordmark).
> Hence, no surprise that it fully reuse "draft-chakrabarti-nordmark-energy-
> aware-nd".
> But sorry I like original draft more, because it did not have complexity of multi-
> link and it did show migration path with mixed-mode link.
> I have not understood why you did mention Ethernet vs WiFi. I did understand
> that all these versions are acceptable for all type of L2 links.
> 
> > > I still see attempts to develop multi-link by OMNI. Hence, in
> > > general, multi-link is needed and valuable thing. Just it should be
> > > optional (separate
> > specification).
> >
> > The multilink complexity that I can think of is the ND proxy. It was
> > effectively split and that split was made in flight while writing RFC
> > 6775, if you care for the real history.
> > That's very different from rejected and that's not WiND. We needed to
> > progress and we did it at 6lo where it was more constructive.
> > > > > Looking to your explanation who is police - I see that it could be only
> SAVI.
> > > > But:
> > > > > IMHO: Multi-link is not the mandatory part of address resolution
> > > > > - it should be
> > > > >> The police has to be enforced by routers or first hop L3
> > > > >> switches and APs. Direct host to host was tried with SEND and that was
> a failure.
> > > > >>
> > > > >> The point I was making is that hosts may be compromised to
> > > > >> misuse their access to the link. So link access control cannot
> > > > >> be good enough; and then there’s the ND DOS attacks that do not
> > > > >> even need link
> > > > access.
> > > > >>
> > > > >> sends ND messages claiming an IP address, owns that address.
> > > > >> The police function at the access switch/router must be aware
> > > > >> of the binding of IP and MAC and preferably be able to
> > > > >> revalidate a proof of ownership for
> > > > >>>> scanning DOS attacks are well known. Patching one of these
> > > > >>>> many holes may add more complexity than benefits, and creates
> > > > >>>> its own side
> > > > effects.
> > > > >>>>
> > > > >>>> Better use a VPN and form a new address if one doesn’t work.
> > > > >>>> If that still fails go to another coffee shop.
> > > > >>>>
> > > > >>>> Certainly this peace and love approach can only be taken so
> > > > >>>> far and environments such as corporate networks already
> > > > >>>> require a better
> > > security.
> > > > >>>> like MACSEC and 1x; but we all know that depending only on
> > > > >>>> the link access control is not enough, and we need at some
> > > > >>>> point to introduce zero trust; in other words, we must deploy
> > > > >>>> some police to enforce the proper use of addresses and
> > > > >>>> services in the
> > network.
> > > > >>>>

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 18 Nov 2020 17:51:41 +0000

Hi Fernando,
Your approach is "all or nothing in exactly one place". I am for everything good too.
OK. Lets wait screaming Enterprise customers. IPv6 migration for ordinary Enterprises (except OTTs) would happen sooner or later - market pressure is too big.
Lets see what would revert some migrations back.

By the way, encryption does not help against MITM. Because majority of Enterprises does not have certification authority infrastructure.
All new sessions would be intercepted. In relation to the problem described in this draft it means: almost all sessions.
Therefore, It is the massive leakage of information. Credentials in 1st place.
Application layer would not help.
Eduard
> Sent: 18 ноября 2020 г. 20:10
> Because RA-Guard is an operational mitigation. that is enforced by the network.
> My expectation is that all issues of the same kind of a given protocol are solved
> at the same place.
> 
> Note: RA-guard mitigates RA-based attacks, not RS-based or Redirect-based
> attacks. For the later two you need ND inspection/FHS, at which point you'd also
> police NS/NA there, too.
> 
> 
> If there is a proble, the problem is ND, not the specific case of NA-based attacks.
> 
> 
> 
> > Full snooping of NS protocol with active solicitation in questionable situations
> on L2 device (SAVI) has not become popular. It is too much for L2 device. > What
> I am proposing is just to count number of NA responses to

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Nov 2020 14:48:03 -0300

On 18/11/20 14:15, Pascal Thubert (pthubert) wrote:
> Your history still does not relate back enough in time. But it does not matter; what matters is not spreading the idea that 6MAN has rejected WiND. 

As far as I am concerned, even then, if that had been the case, one 
could only say "6man rejected the idea*at that *time*". Participants 
change over time, and they may also change their mind.

So it would seem perfectly normal and sensible that an idea that was 
rejected to be brought back say, 5 years later if e.g. there are extra 
insights, operational experience, or whatever.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Nov 2020 15:12:02 -0300

> Your approach is "all or nothing in exactly one place". I am for everything good too.

...*for the same protocol*.

> Lets see what would revert some migrations back.

To be honest, I don't think anybody is going to scream. If they do, then 
one can point to them at FHS, SAVI, RA-Guard, and friends. *Or* they can 
do "one prefix" per host. Or segment the network appropriately.

ND is not that worse than ARP/DHCP in this respect.

> By the way, encryption does not help against MITM. Because majority of Enterprises does not have certification authority infrastructure.

If you want to authenticate and authorize ND messages, that's what it takes.

Me, I don't think SEND will ever fly. And where it matters, folks will 
employ one/many of teh techniques described above.

That said, that shouldn't stop us from improving ND where possible (if 
that can be done in a coherent way that improves all messages), or work 
on replacements (as Pascal has suggested).

> Application layer would not help.

You seem to be confusing MITM with information leakage.

For example, my ISP is by definition, a MITM. Still, where necessary, my 
information doesn't leak because I employ HTTPS/SSH/VPNs where necessary.

Thanks,

---

From: Jen Linkova <[email-masked]>
Date: Thu, 19 Nov 2020 15:46:27 +1100

> Unfortunately, it is not encryption.

IMHO the proper solution for any MitM is authentication and e2e
encryption. That's why we use ssh instead of telnet, https instead of
http and dnssec instead of dns.
That approach is supposed to prevent MitM anywhere on the path between
the client and the server and is IP-version agnostic.
In that regard MitM is less dangerous than DoS.

I have the following concerns re: your proposal:
1. it makes the ND state machine much more complicated.
2. it fundamentally changes the approach of dealing with duplicate
addresses - until now, it's been 'first come-first served', so
whatever happens, the disruption to the existing owner of the address
should be minimized.  The suggested changes might have a very
disruptive impact in the scenarios when duplicated addresses happen
accidentally. More specifically:
2.1 As most implementations send just one DAD packet and multicast on
WiFi is rather unreliable, there is still a chance of getting
duplicated addresses. Currently, if the existing  owner is
sending/receiving traffic, the 'new' host wouldn't be able to override
the cache on the router, so while the 'newcomer' wouldn't work, the
existing owner wouldn't notice anything. Your proposal breaks
connectivity for both devices.
2.2 Let's consider the case of a host implementing an Optimistic DAD
for an address which is already in use on the network. Currently NAs
sent from an Optimistic address wouldn't cause any disruption. The
logic in your draft means NAs from an optimistic address can move the
router cache entry into DUPLICATE state (and if the node supports
GRAND, it certainly will) - even if the address state is going to
become duplicated as soon as DAD is completed.
3. While it is trying to prevent an on-link MitM (remember, it's just
one scenario of MitM) it makes DoS attack. An attacker now can easily
move all entries into DUPLICATE state, breaking the communication for
all hosts for up to 1 hr.

To summarize, looking at pros/cons of the solution, I seriously doubt
it's worth doing.

-- 
SY, Jen Linkova aka Furry