Re: [v6ops] IPv6 link-local traffic questions

Stewart Bryant <stewart.bryant@gmail.com> Fri, 20 March 2020 15:19 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D6D3A09EC; Fri, 20 Mar 2020 08:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8uefOI1A48o; Fri, 20 Mar 2020 08:19:12 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75AC3A09F8; Fri, 20 Mar 2020 08:19:11 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id h9so7929817wrc.8; Fri, 20 Mar 2020 08:19:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oQw3l80YLOHIvxC5YrL558YVDypcKPtQkPVvP0htK7s=; b=Fuf1LxBqJvreus61Aa+w5k8Yz83WwofyihjBEuMKtSYoZLkpXqvL0+LWsshUfDcmuT cLtiOxPPOCeezdovl/29ZyThq+YqOvfexxqcWbI7P85DnjptKZxlZzdYo5duJCpwPIuu p2SSBF92h0P52XroBpvL42QOVKuyvtlitxvcNtQi8zJWDZsGY25vM8W90TxPLho14HLl QAM0gobmXrloa8bclSgyUi4d6jtriyj2Tzb4kG2cK8fDZJBJtY95+jLU4KonrXfRk7eC wxLOymhLs/unfDpc1e/rFB22buBrn81MMxnmTNHKh4w8Ho0i7b53ejYJfF8BjLxrT6FZ 2cFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oQw3l80YLOHIvxC5YrL558YVDypcKPtQkPVvP0htK7s=; b=VBbo2EGrkeKrj4i0x/PvbGIGfvf8+Xqo3+HGucnBDj+ee9KTW0EU5uAMfezWALpOmH hdpBBjglR6R1EtNki9HOPF8mTKE9AWLj6DRogMIEHjZKTofIgcOLJymIrx9BxlqO+fvO sFKmY1xOQ9dXjw0nsCYpi+aL7VGMxwQfkUTN29WPCUhSJLMlDNtvH6LqrTIeK7pyDMbC S+lMNfZ8e/UmfeFY11CqQadIX/A/jcdddqtTEad8c37ZakbLkMQvoU5u4m0KQzxagTP4 zsNFH2JPKG+33vjC/r+QJMoVmcNaoBkkHLsBvV0Bvm/q7Yzb7MuFhfp+Swxxp0waEEsn MVSA==
X-Gm-Message-State: ANhLgQ3BaYNLBzNPcWgWyyb5EzYsXZWzq60JcplzYX99GK1p/YCX9Em+ u3IpO6s5f2zmzAltNl2/Zes=
X-Google-Smtp-Source: ADFU+vsYlNGVwXjcO6P74VVTDmyDs9XasLNojfMRsNPfV3+uQfmmtAlv9t+rGvATe4KjsIDXyrt+OQ==
X-Received: by 2002:a05:6000:cb:: with SMTP id q11mr1724977wrx.25.1584717550040; Fri, 20 Mar 2020 08:19:10 -0700 (PDT)
Received: from broadband.bt.com ([2a00:23a8:4140:0:c881:c394:4fcb:1056]) by smtp.gmail.com with ESMTPSA id i1sm8999916wrs.18.2020.03.20.08.19.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2020 08:19:08 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: [v6ops] IPv6 link-local traffic questions
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <20200320143009.GA19351@faui48f.informatik.uni-erlangen.de>
Date: Fri, 20 Mar 2020 15:19:07 +0000
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Gyan Mishra <hayabusagsm@gmail.com>, 6man <6man@ietf.org>, V6 Ops List <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <046A495C-068F-4F72-8545-003970DF3D25@gmail.com>
References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <CAFU7BAT-LP5TC9dpYw+5j8T8H_8XMF=tcY-Qsbg5=MOgUYNk+A@mail.gmail.com> <CABNhwV1uCFHCO9r3NK7QeqZ4gvrquoD_534LXoykaf59S48rpA@mail.gmail.com> <20200320143009.GA19351@faui48f.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0rTU2xTjXZDSW45Y-Oi16kn4ZIY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2020 15:19:15 -0000


> 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
> --------------------------------------------------------------------