Subject: I-D Action: draft-ietf-6man-grand-01 - additional security concerns

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 29 Jul 2020 19:56:24 +0000

Hi Jen,
You did ask a feedback yesterday about severity of 7sec security hole that has very low probability.
I have intention here to show that probability is 100%, 7sec could be prolonged to forever, and the final result is the full interception of innocent host traffic by intruder (successful "man-in-the-middle").

Pre-request for success:
- no multicast snooping (MLD) and filtering on a switch, that is perfectly possible
- Intruder should be already on the same subnet (gained control over other host by exploiting of different vulnerability)
- intruder should suppress DAD on Intruder's controlled host (is Windows firewall capable to filter out DAD?)
- We assume that we are talking about the future when this draft is used by majority of nodes (victim should use it)

Procedure: 
Intruder's controlled host does listen to all-routers multicast address (ff02::2).
As soon as it would eavesdrop unsolicited NA from victim node (probably after boot) - Intruder would immediately (a few milliseconds) duplicate NA in router's direction, but with 2 changes: (1) his LLA (MAC); (2) Override bit set.
Intruder has time only up to the point that response to victim's traffic would be returned from the Internet (from tens of milliseconds to many seconds if victim would not start sending immediately), - but it is enough time: local communication should be faster.
Theoretically, RetransTimer should be imposed on unsolicited NA (section 7.2.6), but low chances that this timer is checked on receiving side (router), because RetransTimer is specified for transmission side.
According RFC 4681 section 7.2.5 clause II: O bit set should not just rewrite ND cache, but additionally mark ND record as REACHABLE. According to section 7.2.6: " The Override flag (for unsolicited NA) MAY be set to either zero or one". Despite it contradicts to the logic of the whole RFC 4681 (O bit should not be set in unsolicited NA - it is mentioned in a few places of RFC 4681). But because section 7.2.5 and section 7.2.6 clearly permit to use Override flag - higher probability that particular implementation would not just rewrite LLA on router, but additionally put it into REACHABLE.
Intruder could be sure that at least STALE state would be created according to section 7.2.5 clause I, - this ND record would be against his LLA anyway.
After receiving return traffic (if it was created as STALE, not REACHABLE) - router would ask intruder about reachability (solicited NS-NA) - intruder would confirm his LLA - it would finally put ND cache record into REACHABLE.
That's it: upstream traffic of victim host is going to router, traffic back is going through Intruder.
I have consulted with penetration tests professional (these are people with the same qualification as hackers but they play on legal side): what he would be doing next? He said that he would return traffic to legitimate host - victim should not see performance degradation. He would collect cookies and some other valuable information. He would finally see DNS response, change it and redirect everything to himself on the permanent basis - he does want to see both directions of victim exchange. He has qualified Man-in-the-middle as full fiasco - it does open many opportunities for him. He has mentioned very good feature of this draft that there is no any interruption for victim's traffic flow, no any excessive traffic to victim, that is very rear benefit for hacker's tool.

What to do about it?
1. Potentially it is possible to do RPF-like check for Source LLA addresses. Upstream traffic from victim's SLLA would not be in ND cache - such traffic could be discarded. It is better to block communication than permit intruder to exploit vulnerability.
2. Increase RetransTimer and ask receiver side (router) to check on sending side delay between ND record override (for the same SLLA). But how long should be the timer? Host could wait a lo-o-o-ng time before it would request 1st information from internet. It would decrease probability, but would not completely eliminate attack vector.

My proposition for this draft is disruptive:
I believe that ND is very complicated (some could say "fragile") - it is better not to touch it.
Additionally I do not like to wait till all hosts would refresh to new draft (to get new functionality).
I propose to change only router behavior: check Source LLA (MAC) for every packet, if this SLLA is absent in ND cache - then request solicited NS-NA immediately. It would probably resolve faster than traffic would return from the internet.
Effectively I do proposed the same SLLA RPF that is needed to fix current solution, but:
- without any modification to host OSes
- without any modification of standard (it is local recommendation for router, NS-NA is exactly the same from RFC 4681, NA is unicast - it is important for security)
- without any risk to break ND fragile algorithm
- it could be optional, or even configurable on the router as "value add feature" in competitive tender
Because it is just best practice recommendation - may be it make sense to move it to "v6ops"?

PS: Looking to the above - unsolicited NA should be really delayed by additional big timer (not by RetransTimer that is used for solicited NS/NA) and checked on receiver side - this modification of standard is really needed to close Unsolicited NA vulnerability.
Somebody said on the call that it is already a feature of some OS (Android?) - it is bad: it means that this OS is already vulnerable.
It is just important to understand: do they practice it on tethering? I do not see the reason to practice it on 3GPP link.

Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Jen Linkova
Sent: 27 июля 2020 г. 7:49
To: 6man <[email-masked]>
Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt

Hello,

The -01 version addresses comments received (thanks everyone who provided feedback). Also, Section 3 (Avoiding Disruption) has been expanded and discussed a corner case when two devices start using the same address almost at the same time (the second device configures an optimistic address after the rightful owner sent some packets but before the return traffic arrives).
Feedback on the updated section 3.3
(https://tools.ietf.org/html/draft-ietf-6man-grand-01#section-3.3) is very much appreciated.

On Sun, Jul 26, 2020 at 10:14 AM <[email-masked]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Maintenance WG of the IETF.
>
>         Title           : Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers
>         Author          : Jen Linkova
>         Filename        : draft-ietf-6man-grand-01.txt
>         Pages           : 12
>         Date            : 2020-07-25
>
> Abstract:
>    Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the
>    link-layer addresses of neighboring nodes as well as to discover and
>    maintain reachability information.  This document updates RFC4861 to
>    allow routers to proactively create a Neighbor Cache entry when a new
>    IPv6 address is assigned to a node.  It also updates RFC4861 and
>    recommends nodes to send unsolicited Neighbor Advertisements upon
>    assigning a new IPv6 address.  The proposed change will minimize the
>    delay and packet loss when a node initiate connections to off-link
>    destination from a new IPv6 address.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-grand/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6man-grand-01
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-grand-01
>
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
SY, Jen Linkova aka Furry

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

---

From: Jen Linkova <[email-masked]>
Date: Thu, 30 Jul 2020 12:06:46 +1000

> After receiving return traffic (if it was created as STALE, not REACHABLE) - router would ask intruder about reachability (solicited NS-NA) - intruder would confirm his LLA - it would finally put N…

1) the 7 seconds corner case was for 'preventing address collision for
Optimistic DAD', not for any intentional attacks case. Because:
2) What you are describing could be done today, now, anytime w/o the
changes described in the draft. If there is no MLD snooping then the
intruder would see the DAD packet from the victim, so it would know
the victim address anyway  - no reason even to join ff02::2. Now all
the attacker needs to do is to keep sending NA with S=1, O=1 - hoping
that when the first packet of the return flows arrive and the router
creates an INCOMPLETE entry and sends an NS, the attacker's packet
would come before the victim's NA. Done, the  entry is changed to
REACHABLE, all traffic goes to the attacker.
Actually even simpler. The attacker does not need to deal with timing.
Let's say the router has an NC entry for the victim address in any
other state than INCOMPLETE. The attacker sends an NA with S=1, O=1,
Target address = the victim's IPv6 address, the TLLA = the attacker
MAC address.  Done. The router updates the cache entry and changes it
to REACHABLE state.

There is nothing new here. We have the same issue with ARP - the
attacker can override ARP entry on the router.

> I have consulted with penetration tests professional (these are people with the same qualification as hackers but they play on legal side): what he would be doing next? He said that he would return…

For all that doom and gloom the attacker would also need to see the
traffic *from* the victim. Assuming the network has RA Guard in place
it would be a bit harder. If the network does not have RA Guard our
poor victim has much bigger problems already.

> Additionally I do not like to wait till all hosts would refresh to new draft (to get new functionality).

Well, only hosts which want to connect to the network faster need to
implement this. So host OS developers have pretty good incentive here.
Please keep in mind that the proposed behavior is not currently
prohibited. We are not changing any MUST NOT to anything else. All we
are doing is to making some recommendations more explicit.

> I propose to change only router behavior: check Source LLA (MAC) for every packet, if this SLLA is absent in ND cache - then request solicited NS-NA immediately. It would probably resolve faster th…

Have you checked the problem statement draft?
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03#section-3.7
specificatlly?
What you are proposing does make sense, however it would not help in
case of multiple routers. Also I recall some people having strong
opinions on performance implications.

> Because it is just best practice recommendation - may be it make sense to move it to "v6ops"?

See https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03

> Somebody said on the call that it is already a feature of some OS (Android?) - it is bad: it means that this OS is already vulnerable.

I was saying that some routing platforms have this already
implemented. Search for 'glean' here:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configuration/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html

AFAIK there are implementations which are also prepopulating NC from
DAD packets but I can not find you a reference right now.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 30 Jul 2020 08:05:06 +0000

Then it is not logical for me:
Many people understand that "Unsolicited NA" is a big security hole per se,
But instead of fixing it (may be even deprecate - should be investigated)
Additional functionality is building on top of it.
It would additionally challenge this security problem resolution in the future!

Again: "Unsolicited NA" with Override bit set - is a disaster now.
IMHO: it is better to prohibit "Unsolicited NA". Let's wait timers for the case of MAC address change on legitimate host.
May be we could think about other solutions.
But if additional functionality would be built on top of "Unsolicited NA" - less options would be available ("deprecate" would be not a choice anymore).

If something is ill - it should be cured first - bodybuilding make sense only after this.

Jen, I have not understood below why you did mention RA Guard. Intruder does not need it. He just claim (by Unsolicited NA) that his MAC is connected to GUA of victim.
Intruder could claim it every 5 seconds to keep cache in STALE state (for the case of very careful vendor implementation of ND).
As you mentioned - no help from MLD snooping on switches - it would be enough to just listen to DAD. Switch could not help in principle.
The first modified DNS response would convert traffic flow to bi-directional for Intruder.

Ed/
-----Original Message-----
From: Jen Linkova [mailto:[email-masked]] 
Sent: 30 июля 2020 г. 5:07
To: Vasilenko Eduard <[email-masked]>
Cc: 6man <[email-masked]>; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security concerns

On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard <[email-masked]> wrote:
> - Intruder should be already on the same subnet (gained control over 
> other host by exploiting of different vulnerability)
> - intruder should suppress DAD on Intruder's controlled host (is 
> Windows firewall capable to filter out DAD?)
> - We assume that we are talking about the future when this draft is 
> used by majority of nodes (victim should use it)
>
> Procedure:

1) the 7 seconds corner case was for 'preventing address collision for Optimistic DAD', not for any intentional attacks case. Because:
2) What you are describing could be done today, now, anytime w/o the changes described in the draft. If there is no MLD snooping then the intruder would see the DAD packet from the victim, so it would know the victim address anyway  - no reason even to join ff02::2. Now all the attacker needs to do is to keep sending NA with S=1, O=1 - hoping that when the first packet of the return flows arrive and the router creates an INCOMPLETE entry and sends an NS, the attacker's packet would come before the victim's NA. Done, the  entry is changed to REACHABLE, all traffic goes to the attacker.
Actually even simpler. The attacker does not need to deal with timing.
Let's say the router has an NC entry for the victim address in any other state than INCOMPLETE. The attacker sends an NA with S=1, O=1, Target address = the victim's IPv6 address, the TLLA = the attacker MAC address.  Done. The router updates the cache entry and changes it to REACHABLE state.

There is nothing new here. We have the same issue with ARP - the attacker can override ARP entry on the router.

> I have consulted with penetration tests professional (these are people with the same qualification as hackers but they play on legal side): what he would be doing next? He said that he would return…

For all that doom and gloom the attacker would also need to see the traffic *from* the victim. Assuming the network has RA Guard in place it would be a bit harder. If the network does not have RA Guard our poor victim has much bigger problems already.

> Additionally I do not like to wait till all hosts would refresh to new draft (to get new functionality).

Well, only hosts which want to connect to the network faster need to implement this. So host OS developers have pretty good incentive here.
Please keep in mind that the proposed behavior is not currently prohibited. We are not changing any MUST NOT to anything else. All we are doing is to making some recommendations more explicit.

Have you checked the problem statement draft?
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03#section-3.7
specificatlly?
What you are proposing does make sense, however it would not help in case of multiple routers. Also I recall some people having strong opinions on performance implications.

> - without any modification of standard (it is local recommendation for 
> router, NS-NA is exactly the same from RFC 4681, NA is unicast - it is 
> important for security)
> - it could be optional, or even configurable on the router as "value 
> add feature" in competitive tender Because it is just best practice recommendation - may be it make sense to move it to "v6ops"?

> Somebody said on the call that it is already a feature of some OS (Android?) - it is bad: it means that this OS is already vulnerable.

I was saying that some routing platforms have this already implemented. Search for 'glean' here:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configuration/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html

AFAIK there are implementations which are also prepopulating NC from DAD packets but I can not find you a reference right now.

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

---

From: Jen Linkova <[email-masked]>
Date: Thu, 30 Jul 2020 19:58:25 +1000

> But instead of fixing it (may be even deprecate - should be investigated)

There are many attacks possible within the same L2 segment. It's not
new. That's why you shall either block p2p with the LAN (if you do not
trust endpoints in general) or - better - hosts shall use end2end
encryption.

> Additional functionality is building on top of it.

Sorry, I'm not sure I understand why unsolicited NA is the problem
here. The mechanism I described in my previous email is using
*solicited* NA to override the neighbor cache on the router.

> Again: "Unsolicited NA" with Override bit set - is a disaster now.

As well as Solicited, right? ;) Shall we look at SEND again? ;) It
would be great but I'm not aware of implementations being widely
deployed.

> Jen, I have not understood below why you did mention RA Guard. Intruder does not need it. He just claim (by Unsolicited NA) that his MAC is connected to GUA of victim.

Yes, to intercept traffic *to* the victim. How is it going to
intercept packets sent by the victim?

> As you mentioned - no help from MLD snooping on switches - it would be enough to just listen to DAD. Switch could not help in principle.

Strictly speaking, if the switching infrastructure implements MLD
snooping, the attacker would need either to guess the lower 24 bits of
the victim's address or to join 2^24 solicited node multicast address
groups.

> The first modified DNS response would convert traffic flow to bi-directional for Intruder.

That's why DNSSEC and DNS over TLS and HTTPS are good for security.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Jul 2020 19:36:07 +0900

I think the fact is that ND is inherently insecure from on-link attacks. If
security is desired, then it needs to be provided in other ways, such as
via SEND or SAVI. But it's also not particularly desirable to provide
security at this layer. Traffic snooping is not very useful (not zero
utility, but difficult to use well) when all traffic is encrypted, and
on-link DoS attacks just aren't very useful these days given that many
devices have a variety of connectivity options.

On Thu, Jul 30, 2020 at 5:05 PM Vasilenko Eduard <
[email-masked]> wrote:

> IMHO: it is better to prohibit "Unsolicited NA". Let's wait timers for the
> case of MAC address change on legitimate host.
> But if additional functionality would be built on top of "Unsolicited NA"
> - less options would be available ("deprecate" would be not a choice
> anymore).
>
> Jen, I have not understood below why you did mention RA Guard. Intruder
> does not need it. He just claim (by Unsolicited NA) that his MAC is
> connected to GUA of victim.
> Intruder could claim it every 5 seconds to keep cache in STALE state (for
> the case of very careful vendor implementation of ND).
> As you mentioned - no help from MLD snooping on switches - it would be
> enough to just listen to DAD. Switch could not help in principle.
> > I have intention here to show that probability is 100%, 7sec could be
> prolonged to forever, and the final result is the full interception of
> innocent host traffic by intruder (successful "man-in-the-middle").
> >
> > Pre-request for success:
> > As soon as it would eavesdrop unsolicited NA from victim node (probably
> after boot) - Intruder would immediately (a few milliseconds) duplicate NA
> in router's direction, but with 2 changes: (1) his LLA (MAC); (2) Override
> bit set.
> > Intruder has time only up to the point that response to victim's traffic
> would be returned from the Internet (from tens of milliseconds to many
> seconds if victim would not start sending immediately), - but it is enough
> time: local communication should be faster.
> > Theoretically, RetransTimer should be imposed on unsolicited NA (section
> 7.2.6), but low chances that this timer is checked on receiving side
> (router), because RetransTimer is specified for transmission side.
> > According RFC 4681 section 7.2.5 clause II: O bit set should not just
> rewrite ND cache, but additionally mark ND record as REACHABLE. According
> to section 7.2.6: " The Override flag (for unsolicited NA) MAY be set to
> either zero or one". Despite it contradicts to the logic of the whole RFC
> 4681 (O bit should not be set in unsolicited NA - it is mentioned in a few
> places of RFC 4681). But because section 7.2.5 and section 7.2.6 clearly
> permit to use Override flag - higher probability that particular
> implementation would not just rewrite LLA on router, but additionally put
> it into REACHABLE.
> > Intruder could be sure that at least STALE state would be created
> according to section 7.2.5 clause I, - this ND record would be against his
> LLA anyway.
> > After receiving return traffic (if it was created as STALE, not
> REACHABLE) - router would ask intruder about reachability (solicited NS-NA)
> - intruder would confirm his LLA - it would finally put ND cache record
> into REACHABLE.
>
> intruder would see the DAD packet from the victim, so it would know the
> victim address anyway  - no reason even to join ff02::2. Now all the
> attacker needs to do is to keep sending NA with S=1, O=1 - hoping that when
> the first packet of the return flows arrive and the router creates an
> INCOMPLETE entry and sends an NS, the attacker's packet would come before
> the victim's NA. Done, the  entry is changed to REACHABLE, all traffic goes
> to the attacker.
> Let's say the router has an NC entry for the victim address in any other
> state than INCOMPLETE. The attacker sends an NA with S=1, O=1, Target
> address = the victim's IPv6 address, the TLLA = the attacker MAC address.
> Done. The router updates the cache entry and changes it to REACHABLE state.
>
> > I have consulted with penetration tests professional (these are people
> with the same qualification as hackers but they play on legal side): what
> he would be doing next? He said that he would return traffic to legitimate
> host - victim should not see performance degradation. He would collect
> cookies and some other valuable information. He would finally see DNS
> response, change it and redirect everything to himself on the permanent
> basis - he does want to see both directions of victim exchange. He has
> qualified Man-in-the-middle as full fiasco - it does open many
> opportunities for him. He has mentioned very good feature of this draft
> that there is no any interruption for victim's traffic flow, no any
> excessive traffic to victim, that is very rear benefit for hacker's tool.
>
> traffic *from* the victim. Assuming the network has RA Guard in place it
> would be a bit harder. If the network does not have RA Guard our poor
> victim has much bigger problems already.
>
> > What to do about it?
> > 1. Potentially it is possible to do RPF-like check for Source LLA
> addresses. Upstream traffic from victim's SLLA would not be in ND cache -
> such traffic could be discarded. It is better to block communication than
> permit intruder to exploit vulnerability.
>
> > 2. Increase RetransTimer and ask receiver side (router) to check on
> sending side delay between ND record override (for the same SLLA). But how
> long should be the timer? Host could wait a lo-o-o-ng time before it would
> request 1st information from internet. It would decrease probability, but
> would not completely eliminate attack vector.
> >
> prohibited. We are not changing any MUST NOT to anything else. All we are
> doing is to making some recommendations more explicit.
>
> > I propose to change only router behavior: check Source LLA (MAC) for
> every packet, if this SLLA is absent in ND cache - then request solicited
> NS-NA immediately. It would probably resolve faster than traffic would
> return from the internet.
>
> What you are proposing does make sense, however it would not help in case
> of multiple routers. Also I recall some people having strong opinions on
> performance implications.
>
> > add feature" in competitive tender Because it is just best practice
> recommendation - may be it make sense to move it to "v6ops"?
>
> See
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03
>
> > PS: Looking to the above - unsolicited NA should be really delayed by
> additional big timer (not by RetransTimer that is used for solicited NS/NA)
> and checked on receiver side - this modification of standard is really
> needed to close Unsolicited NA vulnerability.
> > Somebody said on the call that it is already a feature of some OS
> (Android?) - it is bad: it means that this OS is already vulnerable.
>
> AFAIK there are implementations which are also prepopulating NC from DAD
> packets but I can not find you a reference right now.
>
> > The -01 version addresses comments received (thanks everyone who
> provided feedback). Also, Section 3 (Avoiding Disruption) has been expanded
> and discussed a corner case when two devices start using the same address
> almost at the same time (the second device configures an optimistic address
> after the rightful owner sent some packets but before the return traffic
> arrives).
> > >         Title           : Gratuitous Neighbor Discovery: Creating
> Neighbor Cache Entries on First-Hop Routers
> > >         Author          : Jen Linkova
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 30 Jul 2020 12:01:24 +0100

Lorenzo Colitti wrote on 30/07/2020 11:36:
> I think the fact is that ND is inherently insecure from on-link attacks.
> If security is desired, then it needs to be provided in other ways, such
> as via SEND or SAVI. But it's also not particularly desirable to provide
> security at this layer.

ND is particularly weak from a security point of view due to its
approach to signalling, i.e. some bits use unicast udp with no token
exchange and/or no acknowledgement.  Without significant incompatible
changes to the protocol, it's difficult to see how this can be improved.

SEND has never been deployed widely and has bootstrap problems which are
difficult to resolve.  Most vendors never bothered implementing it.

SAVI moves the complexity into the L2 forwarding device.  This comes at
a cost, and the more complexity that's thrown into the ND protocol, the
more difficult this becomes.  The ND assigned codepoint registry gives
some clue as to the scale of this complexity:

https://www.iana.org/assignments/icmpv6-parameters

> Traffic snooping is not very useful (not zero

Surely you're joking?

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Jul 2020 20:06:11 +0900

> > devices have a variety of connectivity options.

Actually I should say on-link snooping. Defeating on-link snooping doesn't
seem very useful when it's possible for an on-path attacker to snoop the
traffic at any point between the local link and the destination.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 30 Jul 2020 12:17:14 +0100

Lorenzo Colitti wrote on 30/07/2020 12:06:
> On Thu, Jul 30, 2020 at 8:01 PM Nick Hilliard <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Actually I should say on-link snooping. Defeating on-link snooping
> doesn't seem very useful when it's possible for an on-path attacker to
> snoop the traffic at any point between the local link and the destination.

on-link DoS is a significant security problem for ipv6, all the more so
due to ND's protocol weaknesses.

Nick

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 Jul 2020 21:41:18 +1000

On Thu, 30 Jul 2020, 20:37 Lorenzo Colitti, <lorenzo=
[email-masked]> wrote:

> If security is desired, then it needs to be provided in other ways, such as

+1

More fundamentally, LANs provide any to any connectivity between the set of
attached nodes. That's specifically why they were invented.

That any to any capability means assuming attached nodes will be good
actors and can be trusted not to abuse the any to any capability.

If nodes can't be assumed to be trusted with the any to any capability, you
don't give it to them.

You isolate them from each other at layer 2, so all of their communication
goes through a layer 3 device like a router that can enforce individual
host layer 2 isolation.

Regards,
Mark.

>> Again: "Unsolicited NA" with Override bit set - is a disaster now..
>> IMHO: it is better to prohibit "Unsolicited NA". Let's wait timers for
>> the case of MAC address change on legitimate host.
>> > Intruder has time only up to the point that response to victim's
>> traffic would be returned from the Internet (from tens of milliseconds to
>> many seconds if victim would not start sending immediately), - but it is
>> enough time: local communication should be faster.
>> > Theoretically, RetransTimer should be imposed on unsolicited NA
>> (section 7.2.6), but low chances that this timer is checked on receiving
>> side (router), because RetransTimer is specified for transmission side.
>> > > submission until the htmlized version and diff are available at
>> tools..ietf.org <http://tools.ietf.org>.
>> > >

---

From: joel jaeggli <[email-masked]>
Date: Thu, 30 Jul 2020 05:14:20 -0700

> due to ND's protocol weaknesses.

The signifcant size of subnets and the mechanics or reserving resources
have since inception created resource consumption threats.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 30 Jul 2020 18:34:44 +0000

Hi Jen,
OK. IPv6 SLAAC subnet is not secure in principle and we should abandon any attempt to improve it. Because so many people already spent so much time on this matter - it is just does not make sense to talk again and again.
And the primary solution that they found is the stateful "binding table" on the switch to monitor all NDs (like DHCP/ARP in IPv4), that not many use anyway - we need to fix unsecure solution.

Then your dilemma is not important, 7sec traffic hijacking could not happen unintentionally - probability for address collision on /64 is too low, whatever Interface IDs would be used (collection of RFCs exist).
Eduard
-----Original Message-----
From: Jen Linkova [mailto:[email-masked]] 
Sent: 30 июля 2020 г. 12:58
To: Vasilenko Eduard <[email-masked]>
Cc: 6man <[email-masked]>; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security concerns

On Thu, Jul 30, 2020 at 6:05 PM Vasilenko Eduard <[email-masked]> wrote:
> Many people understand that "Unsolicited NA" is a big security hole 
> per se, But instead of fixing it (may be even deprecate - should be 
> investigated)

There are many attacks possible within the same L2 segment. It's not new. That's why you shall either block p2p with the LAN (if you do not trust endpoints in general) or - better - hosts shall use end2end encryption.

> Additional functionality is building on top of it.

Sorry, I'm not sure I understand why unsolicited NA is the problem here. The mechanism I described in my previous email is using
*solicited* NA to override the neighbor cache on the router.

> Again: "Unsolicited NA" with Override bit set - is a disaster now.

As well as Solicited, right? ;) Shall we look at SEND again? ;) It would be great but I'm not aware of implementations being widely deployed.

> Jen, I have not understood below why you did mention RA Guard. Intruder does not need it. He just claim (by Unsolicited NA) that his MAC is connected to GUA of victim.

Yes, to intercept traffic *to* the victim. How is it going to intercept packets sent by the victim?

> As you mentioned - no help from MLD snooping on switches - it would be enough to just listen to DAD. Switch could not help in principle.

Strictly speaking, if the switching infrastructure implements MLD snooping, the attacker would need either to guess the lower 24 bits of the victim's address or to join 2^24 solicited node multicast address groups.

> > - without any modification of standard (it is local recommendation 
> > for router, NS-NA is exactly the same from RFC 4681, NA is unicast - 
> > it is important for security)
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configura
> tion/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html
>
> > > ------------------------------------------------------------------
> > > -- IETF IPv6 working group mailing list [email-masked] 
> > > Administrative

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 Jul 2020 07:23:12 +1000

On Fri, 31 Jul 2020, 04:35 Vasilenko Eduard, <[email-masked]>
wrote:

> Hi Jen,
> OK. IPv6 SLAAC subnet is not secure in principle and we should abandon any
> attempt to improve it.

GRAND's goal is not and has never been to improve the security of ND. There
is no statement such as "The goal of GRAND is to improve the security of
ND."

This draft describes the problem space.

https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-cache-init/

There are some useful security benefits of the way it will prepopulate
routers' ND caches with nodes' new addresses. However, if none of those
benefits existed, it wouldn't invalidate GRAND as a solution to the problem
GTAND is designed to solve.

Making the primary criticism of GRAND being about ND security is like
criticising a spoon for being a terrible knife.

Regards,
Mark.

Because so many people already spent so much time on this matter - it is
> just does not make sense to talk again and again.
> And the primary solution that they found is the stateful "binding table"
> on the switch to monitor all NDs (like DHCP/ARP in IPv4), that not many use
> anyway - we need to fix unsecure solution.
>
> Then your dilemma is not important, 7sec traffic hijacking could not
> happen unintentionally - probability for address collision on /64 is too
> low, whatever Interface IDs would be used (collection of RFCs exist).
> Eduard
> There are many attacks possible within the same L2 segment. It's not new.
> That's why you shall either block p2p with the LAN (if you do not trust
> endpoints in general) or - better - hosts shall use end2end encryption.
>
> Sorry, I'm not sure I understand why unsolicited NA is the problem here.
> The mechanism I described in my previous email is using
> As well as Solicited, right? ;) Shall we look at SEND again? ;) It would
> be great but I'm not aware of implementations being widely deployed.
>
> > But if additional functionality would be built on top of "Unsolicited
> NA" - less options would be available ("deprecate" would be not a choice
> anymore).
> >
> > Intruder could claim it every 5 seconds to keep cache in STALE state
> (for the case of very careful vendor implementation of ND).
> snooping, the attacker would need either to guess the lower 24 bits of the
> victim's address or to join 2^24 solicited node multicast address groups.
>
> > > As soon as it would eavesdrop unsolicited NA from victim node
> (probably after boot) - Intruder would immediately (a few milliseconds)
> duplicate NA in router's direction, but with 2 changes: (1) his LLA (MAC);
> (2) Override bit set.
> case of multiple routers. Also I recall some people having strong opinions
> on performance implications.
> >
> tools.ietf.org.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Jul 2020 22:26:21 +0000

I disagree with the analogy, Mark.

I support GRAND because it is better than nothing and progressing just that at 6MAN seems to be an incredible achievement already.

But in a world we’re all addresses are proactively installed the router could easily defeat the remote DOS against the cache (that’s an RFC 8505-only network and dhcpv6 vs autoconf is orthogonal to that, we are talking about provisioning the cache not forming the address)

For the insider impersonation attack, SeND may be dead but https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/ Is very much alive. The sad point from an IETF perspective is that it did not come from 6MAN.

Bottom line is that the spoon done right would not leak the soup.

To Jen’s reference we did not only do gleaning in the switch. We also do enforcement. And RA guard. And RA throttling. But an enforcement based on a snooped state is imperfect because we could miss stuff. And it’s all proprietary so it might become a bad idea retrospectively should the protocol change. This is why 10+ years ago we (the group who designed and implemented all this in Cisco routers) proposed the registration model that ended up as RFC 8505.

I wish this group could open its eyes. ND as defined in the last century is not suited for modern fabrics, virtual machines and wireless. It is a pain for silicon-based forwarding. Time to upgrade is overdue.

In the meantime, keep safe.

Pascal

Le 30 juil. 2020 à 23:24, Mark Smith <[email-masked]> a écrit :

On Fri, 31 Jul 2020, 04:35 Vasilenko Eduard, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jen,
OK. IPv6 SLAAC subnet is not secure in principle and we should abandon any attempt to improve it.

GRAND's goal is not and has never been to improve the security of ND. There is no statement such as "The goal of GRAND is to improve the security of ND."

There are some useful security benefits of the way it will prepopulate routers' ND caches with nodes' new addresses. However, if none of those benefits existed, it wouldn't invalidate GRAND as a solution to the problem GTAND is designed to solve.

Making the primary criticism of GRAND being about ND security is like criticising a spoon for being a terrible knife.

Regards,
Mark.

Because so many people already spent so much time on this matter - it is just does not make sense to talk again and again.
And the primary solution that they found is the stateful "binding table" on the switch to monitor all NDs (like DHCP/ARP in IPv4), that not many use anyway - we need to fix unsecure solution.

-----Original Message-----
From: Jen Linkova [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 30 июля 2020 г. 12:58
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security concerns

> Additional functionality is building on top of it.

Sorry, I'm not sure I understand why unsolicited NA is the problem here.. The mechanism I described in my previous email is using
*solicited* NA to override the neighbor cache on the router.

> From: Jen Linkova [mailto:[email-masked]<mailto:[email-masked]>]
> To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
> Cc: 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:v6ops@ietf..org>
> On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
> I was saying that some routing platforms have this already implemented.. Search for 'glean' here:
> > From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jen Linkova
> > To: 6man <[email-masked]<mailto:[email-masked]>>
> > On Sun, Jul 26, 2020 at 10:14 AM <[email-masked]<mailto:[email-masked]>> wrote:
> > >
> > >
> > > submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
> > >
> > > -- IETF IPv6 working group mailing list [email-masked]<mailto:[email-masked]>
> > > Administrative
> > > Requests: https://www..ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
> > IETF IPv6 working group mailing list [email-masked]<mailto:[email-masked]> Administrative
> > Requests: https://www.ietf..org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>

--
SY, Jen Linkova aka Furry
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 31 Jul 2020 14:36:57 +0000

Hi Pascal,

There is nothing broken with IPv6 ND that needs changing; it just needs a new option.
We have seen how that is possible through publications like RFC8801.

BTW, IPv6 itself is a last-century technology but the architects had the wisdom to allow
for future extensions without needing to modify the core architecture.

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, July 30, 2020 3:26 PM
To: Mark Smith <[email-masked]>
Cc: v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: [EXTERNAL] Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns

This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.

Pascal

Le 30 juil. 2020 à 23:24, Mark Smith <[email-masked]<mailto:[email-masked]>> a écrit :

Regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Jul 2020 11:13:21 -0400

> I support GRAND because it is better than nothing and progressing just that at 6MAN seems to be an incredible achievement already. 

Indeed.  GRAND seems like a thing that one would be tempted to add to a stack even in the absence of a draft describing it. Having a draft that describes how to do it is better, because we can then have a discussion of what the benefits and drawbacks are, and mitigate the drawbacks. This concern about ND security seems like a useless digression: yes, ND is not secure, we know this. We’ve tried to address it with SEND, but that hasn’t gotten any traction in the market. 

Are we seeing L2 attacks on ND in the wild? What’s the threat model? If this is a real concern, let’s confront it head-on, rather than trying to address it piecemeal.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 Jul 2020 08:30:29 -0700

> On Jul 31, 2020, at 08:13 , Ted Lemon <[email-masked]> wrote:
> 
> On Jul 30, 2020, at 6:26 PM, Pascal Thubert (pthubert) <pthubert=[email-masked] <mailto:pthubert=[email-masked]>> wrote:

ND attacks are a concern in a very limited number of scenarios, most of which have not had significant v6 penetration yet…

1.	Public wifi networks (e.g. coffee houses, etc.)
2.	College/University settings (some v6 traction here, but often not on student-device accessible LANs)
3.	Other networks which must admit untrusted clients/devices

In reality, ND is not significantly better or worse than ARP in terms of attack surface. The primary difference with ND
is the ability to overrun {switch, router, host} neighbor tables. This doesn’t stem from the difference between ND
and ARP, but rather from the difference between networks that rarely have more than 256 possible L3 addresses
and networks which routinely have more than 18 quintillion possible addresses. There’s just not enough silicon
on the planet for every switch to support an n x 2^64 bit neighbor table.

Indeed, as an operator, IMHO, if there’s a place we need to focus on improving L2 attack surface in v6, it’s in
finding better ways for {routers, hosts, switches} to mitigate/absorb this type of resource exhaustion attack.
Unfortunately, this is a hard problem to solve, so we focus on moving the deck chairs we can move while
ignoring the elephant-sized hole in the bulkheads that we don’t know how to patch.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Jul 2020 11:43:45 -0400

> 1.	Public wifi networks (e.g. coffee houses, etc.)

The BCP for this case is to isolate clients.

> 2.	College/University settings (some v6 traction here, but often not on student-device accessible LANs)

For this it would be to give each dorm room its own subnet.

> 3.	Other networks which must admit untrusted clients/devices

E.g. home networks? Or something else?

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 31 Jul 2020 15:51:08 +0000

Hi Ted, et al,

We’ve tried to address it with SEND, but that hasn’t gotten any traction in the market.

I think that means that either SEND was ahead of its time and the market for it is only
now beginning to materialize, or SEND is somehow broken and should be deprecated.
I am interested to know which, since I believe I see a role for SEND.

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Friday, July 31, 2020 8:13 AM
To: Pascal Thubert (pthubert) <pthubert=[email-masked]>
Cc: v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: [EXTERNAL] Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns

On Jul 30, 2020, at 6:26 PM, Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>> wrote:
I support GRAND because it is better than nothing and progressing just that at 6MAN seems to be an incredible achievement already.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 31 Jul 2020 08:51:40 -0700

Hi,

It’s fine to talk about how to improve ND in this list.

However, please change the subject, I don’t think it’s relevant to "I-D Action: draft-ietf-6man-grand-01”

Bob

> On Jul 31, 2020, at 8:43 AM, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Jul 2020 11:53:27 -0400

> On Jul 31, 2020, at 11:51 AM, Templin (US), Fred L <[email-masked]> wrote:

Yes, it will be interesting to see how this unfolds. I don’t see anybody pushing for SEND at the moment.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 31 Jul 2020 16:10:21 +0000

>> Yes, it will be interesting to see how this unfolds. I don’t see anybody pushing for SEND at the moment.
[>]
I like SEND, and it is written into my documents – is that enough of a push, or do I need
to do more aggressive marketing? Interested in helping?

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Jul 2020 12:12:49 -0400

> to do more aggressive marketing? Interested in helping?

The push would have to be from somebody producing software that has broad reach. And it would have to solve a real problem or nobody with that reach would try to do it.

Does it solve the problem Owen was talking about (overloading neighbor tables as an attack)?  Is there agreement that this is a serious problem in any case?

---

From: Tony Finch <[email-masked]>
Date: Fri, 31 Jul 2020 17:13:22 +0100

Owen DeLong <[email-masked]> wrote:
>
> Indeed, as an operator, IMHO, if there’s a place we need to focus on
> improving L2 attack surface in v6, it’s in finding better ways for
> {routers, hosts, switches} to mitigate/absorb this type of resource
> exhaustion attack. Unfortunately, this is a hard problem to solve, so we
> focus on moving the deck chairs we can move while ignoring the
> elephant-sized hole in the bulkheads that we don’t know how to patch.

If GRAND is deployed, would that allow routers to assume their neighbour
tables are complete, so they can just drop ND exhaustion attacks?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, Southeast Rockall: Westerly or southwesterly 4 or 5. Moderate or
rough. Showers. Good, occasionally moderate.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 31 Jul 2020 16:21:11 +0000

Hello Jen

Since the router is prepopulated, it knows the ND resolution before hosts do.

So say a third party host has traffic to send and the prefix is online. It will store one packet and multicast a lookup to the snma of this node. It will drop the other packets.

An alternate behavior in a network where GRAND is enabled could be to start by forwarding the packets to the router in case of aN ND cache miss.

If the router already has an NCE there will not be a lookup at all. The router will redirect immediately and relay the packets in the meantime. No delay, no loss. And no multicast...

If the router does not have a cache, it will do the NS lookup. And eventually redirect anyway if the traffic continues. Same overall cost, with the benefit that the router now has the cache ready in case yet another host needs it.

Overall benefits day 1, incrementally useful as GRAND gets deployed.

Cherry on the cake: the router may be more SAVI-savvy than this host so it may redirect to the real first-come node.

What do you think?

Pascal

Le 30 juil. 2020 à 12:37, Lorenzo Colitti <lorenzo=[email-masked]> a écrit :

I think the fact is that ND is inherently insecure from on-link attacks. If security is desired, then it needs to be provided in other ways, such as via SEND or SAVI. But it's also not particularly desirable to provide security at this layer. Traffic snooping is not very useful (not zero utility, but difficult to use well) when all traffic is encrypted, and on-link DoS attacks just aren't very useful these days given that many devices have a variety of connectivity options.

On Thu, Jul 30, 2020 at 5:05 PM Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:

Ed/
-----Original Message-----
From: Jen Linkova [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 30 июля 2020 г. 5:07
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security concerns

> > submission until the htmlized version and diff are available at tools..ietf.org<http://tools.ietf.org>.
> >
> [email-masked]<mailto:[email-masked]>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 31 Jul 2020 17:17:43 +0000

Ted, I think SEND would solve the neighbor cache resource exhaustion attack since a NCE is
only created on receipt of an authentic (SEND-protected) IPv6 ND message.

I believe that for aviation networks, intelligent transportation systems, and other mobile node
use cases there will certainly be cases where the mobile node comes onto the network via an
unprotected open-access wireless access network. In that case, the only mitigations would be
for the MN to stand up a VPN (which is expensive overkill) or somehow use IPv6 ND with
appropriate authentication controls applied. SEND seems like agood fit for the latter.

Thanks - Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, July 31, 2020 9:13 AM
To: Templin (US), Fred L <[email-masked]>
Cc: Pascal Thubert (pthubert) <pthubert=[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: Re: [EXTERNAL] Improving ND security

On Jul 31, 2020, at 12:10 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
I like SEND, and it is written into my documents – is that enough of a push, or do I need
to do more aggressive marketing? Interested in helping?

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 31 Jul 2020 17:20:30 +0000

Hi Tone,

> If GRAND is deployed, would that allow routers to assume their neighbour tables are complete, so they can just drop ND exhaustion attacks?

How is it possible to be sure that all hosts do support new draft?
(1) draft does not propose to signal ND version in any way ("Code" is still 0)
(2) Only by separate admin configuration on router, then it is operational practice. No need for standardization.

May be you have asked: is possible in principle?
No, because ND cache could be overwhelmed by Unsolicited NDs, but Unsolicited ND is primary vehicle in the draft.

PS: I was more concerned about "Man-in-the middle" - it is the bigger security problem, not DDoS - albeit it is a big problem too.
Ed/
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Tony Finch
Sent: 31 июля 2020 г. 19:13
To: Owen DeLong <[email-masked]>
Cc: Pascal Thubert (pthubert) <pthubert=[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns

Owen DeLong <[email-masked]> wrote:
> exhaustion attack. Unfortunately, this is a hard problem to solve, so 
> we focus on moving the deck chairs we can move while ignoring the 

If GRAND is deployed, would that allow routers to assume their neighbour tables are complete, so they can just drop ND exhaustion attacks?

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/ Shannon, Southeast Rockall: Westerly or southwesterly 4 or 5. Moderate or rough. Showers. Good, occasionally moderate.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Jul 2020 13:21:40 -0400

> only created on receipt of an authentic (SEND-protected) IPv6 ND message.

OK, but an attacker can just generate a bazillion key pairs, right? So it can still exhaust the cache, at the cost of some computation work.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Jul 2020 13:23:14 -0400

> (2) Only by separate admin configuration on router, then it is operational practice. No need for standardization.

I think I explained why it was worth standardizing from my perspective. Perhaps you disagree with that perspective, but you haven’t said why.   The way you say this makes it sound like you think there’s a downside to standardizing.  Can you explain what that downside is?

---

From: Fernando Gont <[email-masked]>
Date: Fri, 31 Jul 2020 13:58:12 -0300

On 31/7/20 13:12, Ted Lemon wrote:
> On Jul 31, 2020, at 12:10 PM, Templin (US), Fred L 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> */I like SEND, and it is written into my documents – is that enough of 
>> a push, or do I need/*
>> */to do more aggressive marketing? Interested in helping?/*
> 
> The push would have to be from somebody producing software that has 
> broad reach. And it would have to solve a real problem or nobody with 
> that reach would try to do it.
> 
> Does it solve the problem Owen was talking about (overloading neighbor 
> tables as an attack)?  

No, it doesn't.

> Is there agreement that this is a serious problem in any case?

It is a problem... which seems to be more cost-effective solved with 
smaller prefixes for P2P links and/or better management of the neighbor 
cache (e.g. be more aggressive flushing/policing NC entries in the 
incomplete state).

SEND seems to me like a nice idea, but overly complex for the problem 
it's trying to address.

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

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 31 Jul 2020 19:03:05 +0000

On 31 Jul 2020, at 16:58, Fernando Gont wrote:

> smaller prefixes for P2P links and/or better management of the 
> neighbor cache (e.g. be more aggressive flushing/policing NC entries 
> in the incomplete state).

I agree that there are quite a few intelligent things which can be done 
on neighbour tables under attack to a certain level. People had this 
discussions [felt] like a decade ago as well and they should be in the 
archives.

> SEND seems to me like a nice idea, but overly complex for the problem 

It is these unbacked statements which people will use to reason against 
it.
“complex” is not a cause unless it is backed by proper arguments.
“trust distribution” is a thing, which doesn’t really work in a 
coffee shop around the corner.

I do agree that SeND does not solve all the problems either but having 
had it running since Ana Kukec (some might remember her from IETF) did 
this in 2009/2010 for FreeBSD [1] we’ve been shipping a mixed 
kernel/user space solution based on the DoCoMo NTT works which alos run 
on Linux and others.  People later produced WinSeND for Windows [2] and 
their paper read a lot like Ana’s.

I have no idea how the support for major OSes and router vendors is a 
decade later, but I’d be curious if someone would do a proper survey 
and post the results.  I think that would be super helpful (not as an 
RFC, but as a “state snapshot”);  could be a blog post or a cloud 
based spreadsheet somewhere.

/bz

[1] https://wiki.freebsd.org/SOC2009AnaKukec
[2] 
https://hpi.de/meinel/security-tech/next-generation-security-engineering/ipv6-security/winsend.html 
  (I hope the link is good, I cannot currently reach their site)

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 31 Jul 2020 19:20:56 +0000

Fernando,

> From: Fernando Gont [mailto:[email-masked]]
> Sent: Friday, July 31, 2020 9:58 AM
> To: Ted Lemon <[email-masked]>; Templin (US), Fred L <[email-masked]>
> Subject: Re: [v6ops] [EXTERNAL] Improving ND security
> 
[>] 

That is not the case we are meaning to address in the OMNI spec; the
OMNI spec looks at P2MP links with many prospective neighbors. We
like SEND for this use case.

[>] 
[>] 

It is more than a nice idea; it is a key element to the next-generation
(mobile) Internet architecture.

Thanks - Fred

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 31 Jul 2020 19:40:51 +0000

Hi Ted,
I do not understand you.

You did copy my comment that was related to the capability of GRAND to alleviate ND exhaustion attacks. It was separate comment from Tony Finch.

I could repeat again: no, it would not help against this type of attack, even if it would be slightly modified.

But DoS is not extremely big problem – it was not my concern. This concern has been mentioned by many other people in this thread, but not me. This problem is not good too, but I could tolerate it (at least I am ready to trade-off it for performance).

Leakage of information is much bigger problem that I could not tolerate.

May be you are asking me about GRAND in general,
then no - I do not think that it is a good idea to expand functionality using the most valuable feature of ND (Unsolicited NA).
Unsolicited NA is very easy to create a leakage of information. IMHO: it is unacceptable problem that should be fixed first.
If Unsolicited NA would be changed as a result of such ND modification – then GRAND would be based on new version of ND.

Eduard
From: Ted Lemon [mailto:[email-masked]]
Sent: 31 июля 2020 г. 20:23
To: Vasilenko Eduard <[email-masked]>
Cc: Tony Finch <[email-masked]>; Owen DeLong <[email-masked]>; Pascal Thubert (pthubert) <pthubert=[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns

On Jul 31, 2020, at 1:20 PM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
(2) Only by separate admin configuration on router, then it is operational practice. No need for standardization.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 31 Jul 2020 16:30:15 -0300

On 31/7/20 16:03, Bjoern A. Zeeb wrote:
[...]
> It is these unbacked statements which people will use to reason against it.
> “trust distribution” is a thing, which doesn’t really work in a coffee 
> shop around the corner.

SEND implies the use of a PKI. That's non-trivial.

Besides, the expectations for IPv6 are similar to those for IPv4. 
Somehow folks have been able to secure the ipv4 first-hop (when/where 
needed) without the need of understanding something like SEND, or going 
through the hassle of deploying it. So the question "Why do I need this 
for IPv6 when I never required it for IPv4?" may not an easy one to respond.

[...]
> decade later, but I’d be curious if someone would do a proper survey and 
> post the results.  I think that would be super helpful (not as an RFC, 
> but as a “state snapshot”);  could be a blog post or a cloud based 
> spreadsheet somewhere.

I don't seem to remember any major OS that ships with SEND enabled by 
default -- e.g., that configures CGAs over traditional SLAAC or RFC7217.

Additionally (and ironically), the use of IPv6 EHs tends to be rather 
unfriendly to first-hop security.

[....]
>   (I hope the link is good, I cannot currently reach their site)

The link is good. However, it claims "Download: Not available for public 
yet!"

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 31 Jul 2020 19:55:04 +0000

Fernando,

[>] 

We are engineering for a new link model (the OMNI link) which was not previously
used. The link model can support both IPv4 and IPv6 nodes, but both can use SEND.

Again, we are at the dawning of a new era where SEND may finally find its use.

Fred

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 Jul 2020 13:53:28 -0700

> On Jul 31, 2020, at 08:43 , Ted Lemon <[email-masked]> wrote:
> 
> On Jul 31, 2020, at 11:30 AM, Owen DeLong <[email-masked] <mailto:[email-masked]>> wrote:

That doesn’t prevent layer 2 attacks against the switch or router.

> For this it would be to give each dorm room its own subnet.

This doesn’t cover networks in public areas used by students (e.g. quads, cafeterias, student union, etc.).

> E.g. home networks? Or something else?

Something else. I don’t know of a home where one is required to admit untrusted clients onto their network.

Owen