Re: [v6ops] draft-ietf-6man-grand : saving lookups

[Vasilenko Eduard <[e-mail]>]

Hi Pascal,
You proposition for "how to avoid multicast" (by initial redirect through router) is interesting. I would think about it more: it has pros and cons.

But how is it related to GRAND? It should not help to warm-up cache on Router.
GRAND assumes that host sends 1st packet with user data, router does not have proper entry for this host yet.
Redirect function would not help to populate router cache in initial stage (that is GRAND trying to solve).

Or you assume that new host would initially communicate inside subnet (with some other host), that would populate router cache,
And only after this new host would go outside subnet.
IMHO: Host would probably go outside of subnet 1st, because Active Directory, DNS, and many other things.

Eduard
-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: 7 августа 2020 г. 11:33
To: Jen Linkova <[e-mail]>
Cc: 6man <[e-mail]>; IPv6 Operations <[e-mail]>; Jen Linkova <[e-mail]>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups

Hello Jen

I'm effectively describing the behavior of the host when the prefix is not on-link, in combination with GRAND. Together, they can mostly eliminate multicast lookup., which is, well, grand.

As I read it, the L bit when reset indicates an address from that prefix is not signaled to be reachable on the multicast domain. IOW It may or may not be reachable. So the RFC 4861 address resolution may not work, better not use it. Instead pass the packets to the router to route beyond the broadcast domain. 

So yes, one quick and dirty way to get there would be to RECOMMEND that the prefix is advertised as not on-link (L=0) in general. We get the correct operation, but then this defeats the semantics of the bit, doesn't it?

- ITOH, the L bit is a valuable signal to indicate NBMA topologies, multilink subnets etc... We want to avoid NS(lookup) in a topology like that. We are using that heavily in LLNs and mandating it in the backbone router draft, problem solved there (see    
https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-20#section-7). 

- OTOH, if we set it also in transit links, we get the right behavior but lose the indication that the prefix is onlink though we do not want multicast resolution. So though using the L bit would get us there, at the same time that would make it lose an important part of its substance.

Note that in a real NBMA, it can be quite risky to redirect. e.g., in FR or ATM, the router does not know if there is a circuit between a pair of hosts, and what DLCI (VPI/VCI) that would be. Ideally the L bit reset would be an indicator that there is no direct host to host.

So what I'm after is the host behavior of "not onlink" for the lookup phase, the router behavior of onlink for the redirect phase, and the L bit set iff the link is P2P or a transit. E.g., in a distributed fabric, all addresses "reside on-link and can be reached directly without going through a router" and yet we want to avoid broadcast lookups.

Take care,

Pascal

> -----Original Message-----
> From: Jen Linkova <[e-mail]>
> Sent: vendredi 7 août 2020 04:04
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: Jen Linkova <[e-mail]>; IPv6 Operations <[e-mail]>; 
> 6man <[e-mail]>
> Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups
> 
> HI Pascal,
> 
> Sorry for not responding, vacation..
> 
> It looks to me that what you are suggesting can be achieved by setting 
> L bit to zero in PIOs. In that case hosts would send all traffic to 
> routers and upon receiving a redirect would learn that the given destination is actually on-link.
> Or am I missing anything?
> 
> On Sat, Aug 1, 2020 at 2:21 AM Pascal Thubert (pthubert) 
> <pthubert=[e-mail]> wrote:
> >
> > 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=[e-mail]> 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
> <vasilenko.eduard@huawei..com> wrote:
> >>
> >> 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:[e-mail]]
> >> Sent: 30 июля 2020 г. 5:07
> >> To: Vasilenko Eduard <[e-mail]>
> >> Cc: 6man <[e-mail]>; [e-mail]
> >> Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional 
> >> security concerns
> >>
> >> On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard
> <[e-mail]> wrote:
> >> > 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.
> >>
> >> 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.
> >>
> >> > 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.
> >>
> >> 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.
> >>
> >> > 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).
> >>
> >> 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 than 
> traffic would return from the internet.
> >>
> >> Have you checked the problem statement draft?
> >> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-ini
> >> t-
> >> 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.
> >>
> >> > 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"?
> >>
> >> See
> >> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-ini
> >> t-
> >> 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.
> >>
> >> 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/config
> >> ur ation/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: ipv6 [mailto:[e-mail]] On Behalf Of Jen 
> >> > Linkova
> >> > Sent: 27 июля 2020 г. 7:49
> >> > To: 6man <[e-mail]>
> >> > 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 <[e-mail]> 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 [e-mail] 
> >> > > Administrative
> >> > > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> > > ---------------------------------------------------------------
> >> > > --
> >> > > ---
> >> >
> >> >
> >> >
> >> > --
> >> > SY, Jen Linkova aka Furry
> >> >
> >> > -----------------------------------------------------------------
> >> > --
> >> > - IETF IPv6 working group mailing list [e-mail] 
> >> > Administrative
> >> > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> > -----------------------------------------------------------------
> >> > --
> >> > -
> >>
> >>
> >>
> >> --
> >> SY, Jen Linkova aka Furry
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> --
> SY, Jen Linkova aka Furry
_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops