Re: draft-ietf-spring-srv6-network-programming: NH=59 action item closure

Mark Smith <markzzzsmith@gmail.com> Tue, 17 September 2019 02:07 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 5C2731200F8; Mon, 16 Sep 2019 19:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 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_HELO_NONE=0.001, 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 QppZ7ObmrGgx; Mon, 16 Sep 2019 19:07:32 -0700 (PDT)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::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 7D50E1200E7; Mon, 16 Sep 2019 19:07:32 -0700 (PDT)
Received: by mail-oi1-x22b.google.com with SMTP id w144so1494316oia.6; Mon, 16 Sep 2019 19:07:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gLS/pRPk6TnC1JM6kp4kOJ4f+l8oFOr2z+preE/KL+4=; b=ZpgmpQ3Q9jeDy4FgFsK6zNBJdI0EnnmuaXx4+K9qQoQclcpTl7Ix3RCkWPhmSjaUtA EyJAmbNvHjY5ju8P12N1PovTdKYa+Tjogd4mHhFqpL+iAlzmEr//kZsDm01MNLPqtIhR SLOfN31j3ASM8dysu8ltFGFYAp8MiL/VoInoWRwzuHS1kOMnmO6MroaR0izuZ0jDIfQr 9vIDuCmUHJhPknV/MP1k5+j1QtdpLlIlrX3bSUlKCXpyt7BssiQT+w7hmyKgTblXc5HN mkJq8fnfb8s6uxRHZZx+bDEErJzhrDgap0m0zebVv3Zr7DuptNqo0HkVMpNV0f8mVo1Z VmRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gLS/pRPk6TnC1JM6kp4kOJ4f+l8oFOr2z+preE/KL+4=; b=FKbg8rVAkvuxV7mHgDhNipcfXNvp7P7cIbfwZ1EtSbal063A8RQrUGzW3Q8FvrX0c0 3OTdaQgny201J55oH1ljWx6gEJaj4DambPzQG5NABr1XQcKudPVrw0XfJ8VaCIdTs0om JShFUnO+fou/1dtdxLYEDgZ1/kuBsrdV1xsm/+Pv+xdkggeVKfucWW15tEtOJmq/ThWd I19CaSHJPVQmsz0GQIOnkHQXy/GFevklwW07pA0xLvLqEWRl+cfWoR4Az0OCODUih0nR R7MUupYohkJ6Lh91cWiE6yXqU84dOk/mA78ZHm5NUlqqQXNw+f/U28bAkHC8O7PTyoiI HJtw==
X-Gm-Message-State: APjAAAW24aV2ACZJi7VrYsJ1E92vEUSmfbJRpV06826jkFzhKtVFiQ3w eM+VEp+brdwlS12oMLE7ac/J06QustVqYjspxy4=
X-Google-Smtp-Source: APXvYqz3GEYKpQlBz1yjs3fR7hHoTei0GqR+budlyEGGdmtDt5+kietUKs7VbDyeWeFW/6+jgf3kTi7plp6ZegKAOaQ=
X-Received: by 2002:aca:5588:: with SMTP id j130mr1946621oib.38.1568686050567; Mon, 16 Sep 2019 19:07:30 -0700 (PDT)
MIME-Version: 1.0
References: <D57D1C4A-277B-4AC5-990F-FB174AC1130C@cisco.com> <CALx6S34Acm6rZ=M0McWr=XKzygm4H=0fYn6fvGf_Y5k+qod-Gw@mail.gmail.com> <89AA4FDD-9812-48CD-8473-6E38E336E57F@cisco.com> <53236a02-a736-b40f-d885-78e0036af416@gmail.com>
In-Reply-To: <53236a02-a736-b40f-d885-78e0036af416@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 17 Sep 2019 12:07:03 +1000
Message-ID: <CAO42Z2yv=ziqCq7ZDQT6Q5Nyji0CP57vudz=KjTXhSqJ0rKvHA@mail.gmail.com>
Subject: Re: draft-ietf-spring-srv6-network-programming: NH=59 action item closure
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, Tom Herbert <tom@herbertland.com>, SPRING WG <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/eHNMytTlslgVIbOSb5cYMso8SpQ>
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: Tue, 17 Sep 2019 02:07:35 -0000

On Tue, 17 Sep 2019 at 06:34, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>
> Pablo,
>
> On 17-Sep-19 07:44, Pablo Camarillo (pcamaril) wrote:
> > Hi Tom,
> >
> > I agree with your suggestion. What do you think of the following text?
> >
> > <OLD>
> >    9.  IANA Considerations
> >
> >
> >       This document requests the following new IANA registries:
> > </OLD>
> >
> > <NEW>
> >    9.  IANA Considerations
> >
> > This document requests IANA to allocate a new IP Protocol Number value for “Opaque” with the following definition:
> > The value TBD in the Next Header field of an IPv6 header or any extension header indicates that the payload is interpreted via a semantics previously established between the source and destination.
>

Is there really any need for this?

An opaque protocol could be encoded using UDP with end-point agreed
ephemeral source and destination ports. That would provide a
distinguisher in the packet that identifies the end-point agreed
semantics. This distinguisher would almost be essential for any
troubleshooting based on a packet capture.

Isn't this also creating an opportunity for IETF WGs to bypass IANA,
creating their own registry, likely run badly?

Surely all IETF developed protocols should be required to get IANA
approved protocol, port, type, code numbers if they need fixed ones,
or be required to use dynamic numbers such as UDP ports? Isn't
transparency, with exception to when encryption is purposely applied,
the fundamental definition of an open protocol?

if this IP protocol value goes ahead, then I think it should be called
"Proprietary", and restricted to non-IETF developed protocols.

(And this is ignoring that past proprietary protocols such as EIGRP
applied for and received IANA official protocol values.)


Alternatively, isn't this Opaque NH value really saying that the upper
layer protocol identifier information has been shifted into the
packet's address information?

If payload type and transport layer information is being shifted into
the packets' address fields, isn't effectively shrinking the IPv6
address field size from 128 bits to 128 minus the bits required to
identify the upper layer protocol type and identifier bits?

Both Multicast formally and anycast informally encodes service or
function information in addresses. I still think it is necessary to
have upper layer transport protocol headers and identifiers (ports),
to allow for the case where a single identifier allocated to a service
or function e.g. "Name Resolution", can be implemented using different
protocols (UDP/TCP 53 DNS, DoH, DoT).

Another example would be a "Time Synchronisation" service, with a
single address, provided over possibly RFC 868 time protocol, NTP,
PTP, or Time over HTTPS (http://phk.freebsd.dk/time/20151129/)

Regards,
Mark.


> That seems clear enough. I would expect an addition to draft-ietf-opsec-ipv6-eh-filtering, however. Something like:
>
> 3.4.x.  Opaque (Protocol Number=TBD)
> ...
> 3.4.x.3.  Specific Security Implications
>
>    The security implications of the Opaque header are completely unknown.
>
> 3.4.x.4.  Operational and Interoperability Impact if Blocked
>
>    The impact is completely unknown.
>
> 3.4.x.5.  Advice
>
>    Intermediate systems should discard packets containing Opaque unless
>    explicitly configured to allow it.
>
> Regards
>    Brian
>
>
> >
> >       This document requests the following new IANA registries:
> > </NEW>
> >
> > Any feedback or other text proposal is welcome.
> >
> > Many thanks,
> > Pablo.
> >
> >
> > -----Original Message-----
> > From: Tom Herbert <tom@herbertland.com>
> > Date: Thursday, 12 September 2019 at 21:12
> > To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
> > Cc: SPRING WG <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
> > Subject: Re: draft-ietf-spring-srv6-network-programming: NH=59 action item closure
> >
> >     On Thu, Sep 12, 2019 at 10:02 AM Pablo Camarillo (pcamaril)
> >     <pcamaril@cisco.com> wrote:
> >     >
> >     > Hi all,
> >     >
> >     > Following the comments from IETF105, the working group preferred to allocate a new Next Header value.
> >     >
> >     > The authors would like to propose this diff. Any feedback is welcome.
> >     >
> >     > <OLD>
> >     >
> >     >    9.  IANA Considerations
> >     >
> >     >
> >     >
> >     >
> >     >
> >     >       This document requests the following new IANA registries:
> >     >
> >     > </OLD>
> >     >
> >     >
> >     >
> >     >
> >     >
> >     > <NEW>
> >     >
> >     >    9.  IANA Considerations
> >     >
> >     >
> >     >
> >     > This document requests IANA to allocate a new IP Protocol Number value for “SRv6 payload” with the following definition:
> >     >
> >     > The value TBD in the Next Header field of an IPv6 header or any extension header indicates that the payload content is identified via the segment identifier in the IPv6 Destination Address.
> >     >
> >     This seems like an extremely narrow use case to justify an IP Protocol
> >     Number allocation. If this is the route taken, I would suggest to
> >     define something more generic like "Interpreted" which could mean that
> >     there is a next header, but it's interpretation requires information
> >     elsewhere in the packet. That way the number could potentially be used
> >     in other contexts than just SR.
> >
> >     Tom
> >
> >     >
> >     >
> >     >       This document requests the following new IANA registries:
> >     >
> >     > </NEW>
> >     >
> >     >
> >     >
> >     > We would propose to submit a revision with this text on the IANA section of NET-PGM beginning of next week.
> >     >
> >     > Thanks,
> >     > Pablo.
> >     >
> >     > --------------------------------------------------------------------
> >     > IETF IPv6 working group mailing list
> >     > ipv6@ietf.org
> >     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >     > --------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------