Re: [v6ops] IPv6 link-local traffic questions

Thank, Stewart,

Yes, i know.

My question was specifically wrt. mentioning of PSIRT bugs by Gyan,
sorry if my reply was unclear. Of course only interested in 
any additional security insight that is public and related to the
choice of TTL by ND, not any vendor internal / implementation
bug issues.

Cheers
    Toerless

On Fri, Mar 20, 2020 at 03:19:07PM +0000, Stewart Bryant wrote:
> 
> 
> > On 20 Mar 2020, at 14:30, Toerless Eckert <tte@cs.fau.de> wrote:
> > 
> > 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
> 
> 1 anyone can fake.
> 
> 255 can only come from a neighbour which it is used as a simple security check.
> 
> Stewart
> 
> 
> > 
> >> 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 <furry13@gmail.com> wrote:
> >> 
> >>> On Thu, Mar 12, 2020 at 11:01 AM Toerless Eckert <tte@cs.fau.de> 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
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>> 
> >> 
> >> 
> >> -- 
> >> 
> >> Gyan  Mishra
> >> 
> >> Network Engineering & Technology
> >> 
> >> Verizon
> >> 
> >> Silver Spring, MD 20904
> >> 
> >> Phone: 301 502-1347
> >> 
> >> Email: gyan.s.mishra@verizon.com
> > 
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> > 
> > 
> > -- 
> > ---
> > tte@cs.fau.de
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------

-- 
---
tte@cs.fau.de