Re: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Mark Smith <markzzzsmith@gmail.com> Wed, 15 February 2017 20:41 UTC

Return-Path: <markzzzsmith@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 3D0011297CD; Wed, 15 Feb 2017 12:41:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 m8qb3UdXOEsG; Wed, 15 Feb 2017 12:41:51 -0800 (PST)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 93D9C12943B; Wed, 15 Feb 2017 12:41:50 -0800 (PST)
Received: by mail-ua0-x22b.google.com with SMTP id 96so113756649uaq.3; Wed, 15 Feb 2017 12:41:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tRO1/JwjloxzaaDLnA+Pr6Y37uxXrzmKqYreEiCnE3Y=; b=pttWczG0+SPIAgfhelWG6lWkDgjhhe/L7dcQqB5DBH1ZMwCIDcG1U10/LElO13rNIq nLJ1DXd5J+28jj8JDHu0QH1ciUzRbj+knlCg7vY3RRSvcDyaqWKUqG3a9MQWoJUQKO88 +nSEks7zJaAYTB08DOqFq2cGFNvN7cBTR06AY4+x0Y1Eri3qKiWLdWlY4v3CMDEI3R3g TO31N3aGMuTWIOxGRODPUaChJ5iTGG85xj8/gHHVfS54X8jwrGBjp8Rcg+VoZaGhvQXf wNkk05MhD8NLUPR5E7RU83lNPfT5PpU556UjDy4dorhYumbhdnR2Uqld+FS7Zb0tS9pU s0YA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tRO1/JwjloxzaaDLnA+Pr6Y37uxXrzmKqYreEiCnE3Y=; b=pjNqPsRgMRQw8O7TkpRaZujHT2iw3d1Rd7HVbpJPacNljiHprFdruicB0HEuFUNUYf EZ1dnzHOfVUNmHLa6iYtV63a5y1EOy96X+MnnPlAXB9S0VnEsmXa1usDSQ+z4LGtHzlQ Y1JPvO3aHKCq4YJis/jMN/8sZTzEvHALIGFXbhvD8SECjrd27795zQasgUSabZHlvTOM fMmOOQn/dDgo8dDc3fMOyw4vh4MyH5cowcWXQyUIKWGuVganp7ER2nsGtOxDlmKUDxoc /QIdEe37zTk4Ho8zQOA/ooRQYAyJ/bZBXu28Uuvc6GXoKHHtaIS60vNXpIOy2ZKzKaic gVlw==
X-Gm-Message-State: AMke39lGhBHlqp/jDX3qumXg8GYb2bHVrOID3IkVIpVN+xBYIb7qvDrF3rlGNME3hGe7kHXK5BWj8b80XDOYSA==
X-Received: by 10.176.3.44 with SMTP id 41mr19083081uat.157.1487191309528; Wed, 15 Feb 2017 12:41:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.81.230 with HTTP; Wed, 15 Feb 2017 12:41:19 -0800 (PST)
In-Reply-To: <HE1PR0501MB21381B97CAB3707DB7D20F31B6580@HE1PR0501MB2138.eurprd05.prod.outlook.com>
References: <67ab3d39d55840c8a207e2104e6020cd@IL-EXCH01.marvell.com> <CAO42Z2zcc-wCtdbs4VFSu-yWUT0u2PX8r+wpe3Jsj-4vVZUwwg@mail.gmail.com> <eeaa0cc49e104cc68c5b2ae23c44e355@IL-EXCH01.marvell.com> <HE1PR0501MB21381B97CAB3707DB7D20F31B6580@HE1PR0501MB2138.eurprd05.prod.outlook.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 16 Feb 2017 07:41:19 +1100
Message-ID: <CAO42Z2wVBGexYezAzx-Lnmsig2CeErAnTqniv-+7TLRG7XBayQ@mail.gmail.com>
Subject: Re: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: David Mozes <davidm@mellanox.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/q1rfxy8fEuHSgoDkNnUU63doJIU>
Cc: "6man@ietf.org" <6man@ietf.org>, "draft-ietf-6man-rfc2460bis@tools.ietf.org" <draft-ietf-6man-rfc2460bis@tools.ietf.org>, IETF Discussion list <ietf@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 15 Feb 2017 20:41:53 -0000

On 15 February 2017 at 01:27, David Mozes <davidm@mellanox.com> wrote:
> Hi * ,
> I am also supporting the insertion of in-band telemetry like INT along with the  actual data packet .

I think it will cause more trouble than any benefits it provides - of
which nobody has described when I've asked multiple times, and the
only one I can think of is to avoid the overhead of full
encapsulation.

> It is for sure a valid use case for the modern networking including data center.
> There are several proposals how to embedded telemetry information   some of them are with in nvo3 tannling protocols
> (Vxlan-GPE,Geneve) Spring and other  .
> I think that ipv6 hbh is the "cleanest"  way to add such info.
>         1) I don't see any and advantages on the other  proposals (NVO3 ,SPRING) over IPV6 hbh.
>         2))As far as security In the IPsec community, AH is pretty much considered deprecated, a failed experiment.They  are  prefer to use   ESP for authentication as well.
>
> The postal system and the letter is very nice e example

It is not an example of insertion. The postal system uses
encapsulation to add information to letters, leaving the envelope and
its contents alone. Envelops might be a thin integrity barrier,
however the postal system usually has laws to make that integrity
barrier much stronger.

>. I will treat the adding ipv6-hbh info as stamps on the envelops ,since we are not touching  the data gram itself just the envelope

EH's are not equivalent to stamps on envelopes, they're equivalent to
pages inside the envelope. The pages inside the envelop are only
intended to be read by the recipient identified by the destination
address on the envelop.

Sorry for excessive bolding, but I'm getting tired of quoting this
text and having it ignored. RFC2460:

"With one exception, extension headers are *not* *examined* or *processed*
   by *any node* along a packet's *delivery path*, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   *identified* in the *Destination Address* field of the IPv6 header."

"The exception referred to in the preceding paragraph is the Hop-by-

   Hop Options header, which carries information that must be examined
   and processed by every node along a packet's delivery path, including
   the source and destination nodes.  The Hop-by-Hop Options header,
   when present, must immediately follow the IPv6 header.  Its presence
   is indicated by the value zero in the Next Header field of the IPv6
   header."

In other words no mid-flght insertion allowed, even of the HBH option.






>
> Thx
> David
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tal Mizrahi
> Sent: Tuesday, February 14, 2017 3:37 PM
> To: Mark Smith <markzzzsmith@gmail.com>
> Cc: draft-ietf-6man-rfc2460bis@tools.ietf.org; 6man@ietf.org; IETF Discussion list <ietf@ietf.org>; 6man-chairs@ietf.org
> Subject: RE: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
>
> Hi Mark,
>
> I certainly agree that hop-by-hop insertion/modification introduces potential security vulnerabilities.
> Therefore, as I pointed out below, I would recommend to tackle this by defining something along the lines of “Hop-by-hop extensions can be inserted/removed/modified/processed by intermediate nodes *if* [……..] and the possible consequences are [……..]”
>
> For example, hop-by-hop handling can be restricted only to a single administrative domain, or only to tunnels (as in the zero checksum case).
>
> Regards,
> Tal.
>
>>-----Original Message-----
>>From: Mark Smith [mailto:markzzzsmith@gmail.com]
>>Sent: Monday, February 13, 2017 6:07 PM
>>To: Tal Mizrahi
>>Cc: 6man@ietf.org; IETF Discussion list; draft-ietf-6man-
>>rfc2460bis@tools.ietf.org; 6man-chairs@ietf.org
>>Subject: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt>
>>(Internet Protocol, Version 6 (IPv6) Specification) to Internet
>>Standard
>>
>>External Email
>>
>>----------------------------------------------------------------------
>>Hi,
>>
>>
>>
>>On 14 February 2017 at 00:43, Tal Mizrahi <talmi@marvell.com> wrote:
>>> Hi,
>>>
>>>
>>>
>>> Good discussion regarding the text about the hop-by-hop extension.
>>>
>>>
>>>
>>> In my opinion there is a valid use case for intermediate nodes that
>>> insert/remove/modify/process hop-by-hop extensions. Examples: IOAM, INT.
>>>
>>> Since there is a use case, I believe we need explicit text about
>>> intermediate handling of hop-by-hop extensions.
>>>
>>
>>
>>Imagine you sent a letter through the postal system, and the postal
>>system wanted to add information to that letter, that is then to be
>>removed before the letter arrives at its final destination.
>>
>>The postal system have at least two choices as to how to add that information.
>>They could:
>>
>>(a) unstick your envelope's seal, insert the information, reseal the
>>envelope so well you can't tell and send it on its way, some how
>>flagging to a destination device within the postal system that this
>>specific envelop needs to be openned, a specific page removed, and then resealed.
>>
>>(b) take a new envelope with new internal postal system source and
>>destination address information, insert your letter without touching it
>>in addition to the new information, and then sending it on its way.
>>
>>Imagine that the information to be added by the postal system is
>>printed on the same type of paper and is written in the same font as
>>you've chosen to use to write your letter.
>>
>>Have a think about these two methods, what could fail with each of
>>them, and what the consequences may be if any of those failures occur.
>>Have a think of the benefits of each method, and whether they're worth
>>it compared to the failure mode costs and consequences for the method.
>>
>>>
>>>
>>> This [somewhat] reminds me of the discussion a few years ago about
>>> the IPv6/UDP zero checksum. The WG ended up defining that “Zero
>>> checksum is permitted in IPv6/UDP *if* [……..] and the possible consequences are [……..]”.
>>>
>>>
>>
>>That is a far more trivial change to the packet - it is allowing a
>>value in an existing field that was formerly prohibited, and nodes that
>>did not understand that value would drop the packet because that is
>>what they had been specified to do if they received this prohibited value. In other words, existing implementations '
>>behaviour when this formerly unexpected value was encountered had
>>already been specified and deployed.
>>
>>
>>>
>>> I would argue that regarding hop-by-hop extension handling we also
>>> need to define that “Hop-by-hop extensions can be
>>> inserted/removed/modified/processed by intermediate nodes *if* [……..]
>>> and the possible consequences are [……..]”.
>>>
>>
>>Some things that are possible to do in theory shouldn't be done in
>>practice, because the consequences when their implementations fail can
>>be severe and outweigh the benefits.
>>
>>In theory, inserted EHs will be removed 100% of the time. In practice
>>they won't be, because implementations can have bugs and they can also
>>fail in unexpected ways e.g., hardware faults.
>>
>>Regards,
>>Mark.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------