Re: [v6ops] IPv6 link-local traffic questions

[Toerless Eckert <[e-mail]>]

On Sat, Mar 14, 2020 at 02:07:34AM -0400, Gyan Mishra wrote:
> Jen
> 
> I always wondered why RFC 4862 states that ND & RD packets have TTL 255.
> We have run into so many PSIRT bugs with ND which makes it more problematic
> having the TTL 255.

Is there anything that would makes you think 255 is a worse
choice for security than 1 ? Or is it just implementation bugs ?

Cheers
    Toerless

> Since ND & RD packets would always be local scope in your response to
> Toreless you mentioned that GTSM that ND using 255 is kind of an example of
> GTSM in the sense that the TTL is set to 255 for a direct neighbor
> adjacency.  I think though the security issues of TTL 255 with ND/RD
> packets seem to make security a bigger issue then just leaving TTL=1.
> 
> Gyan
> 
> On Wed, Mar 11, 2020 at 8:34 PM Jen Linkova <[e-mail]> wrote:
> 
> > On Thu, Mar 12, 2020 at 11:01 AM Toerless Eckert <[e-mail]> wrote:
> > >
> > > Sorry for cross posting, but this is both ops and arch questions.
> > >
> > > I was trying to find any generic description that/if link-local IPv6
> > > traffic MUST/SHOULD use Hop-count 1, but could not find one in
> > > rfc8200 or rfc4291 and its updates. Instead, text like
> > > MUST set Hop-limit to 1 is repeated in various RFCs using link-local
> > > IPv6 traffic.
> >
> > I believe it depends what you are trying to achieve. If you want to
> > make sure that the traffic never leaves the network - then hop limit =
> > 1 helps. But using link-local sources/destinations would help even
> > better if the routers comply with RFC4291 Section 2.5.6
> > If you want to make sure those packets are not sent by a malicious
> > party from outside - hop limit shall be 255.
> > For example, see RFC4861 Section 3.1
> >
> > > Am i overlooking something ? Or is this intentional in the IPv6
> > architecture ?
> > >
> > > If intentional, i guess it means: Any RFC introducing some type of
> > link-local
> > > traffic can specify Hop-limit requirements for its traffic. As in
> > > "our WG likes 42 as the Hop-limit" (silly to me, but should be fine with
> > > IPv6 architecture then, right ?).
> > >
> > > In one of my draft document reviews using such link-local IPv6 traffic,
> > > EricV brought up the Q if that traffic shouldn't use RFC5082 instead
> > > of Hop-Count 1 too. But given how we do not seem to have architectural
> > > recommendations for TTL=1 (unless, quite likely i overlook something),
> > > and given how i am not aware of any actual use of GTSM, i am quite
> > > weary to go down that route. Aka: Would like learn of actual uses of
> > > GTSM with IPv6.
> >
> > Neighbor Discovery.
> >
> > > There is an additional set of consideration re. link-local traffic
> > > when trying to use it as a HW accelerated tunneling mechanism across
> > links,
> > > a use we both have in ANIMA, and maybe get the same in BIER (probably
> > > other WGs too, not sure).
> > >
> > > In implementations, i have seen quite a range of issues with
> > > accelerated forwarding planes across link-local addressed tunnels,
> > > and when using non-link-local addresses (loopback addresses),
> > > the HW plane forwarding might have issues doing HW forwarding, because
> > > usually TTL=1 is only used for control plane traffic. Of course,
> > > this is not a good architectural argument, but if given architectural
> > > leeway to even choose 42, maybe GTSM/255 is easier to be supported
> > > across various HW accelerated forwarding planes than 1.
> > >
> > > Opinions and experiences welcome!
> >
> > If you control the router I'd say 'link-local source/destination,
> > HL=255 AND RFC4291 would be the best option.
> >
> > I did see a few devices somewhere far away sending me ICMPv6 (packet
> > too big) from their link-local addresses but it was not very common
> > case.
> >
> > --
> > SY, Jen Linkova aka Furry
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> 
> -- 
> 
> Gyan  Mishra
> 
> Network Engineering & Technology
> 
> Verizon
> 
> Silver Spring, MD 20904
> 
> Phone: [phone]
> 
> Email: [e-mail]

> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops


-- 
---
[e-mail]