Re: I-D Action: draft-voyer-6man-extension-header-insertion-07.txt

Mark Smith <markzzzsmith@gmail.com> Mon, 14 October 2019 21:15 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 3A10B12003F for <ipv6@ietfa.amsl.com>; Mon, 14 Oct 2019 14:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 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, HTML_MESSAGE=0.001, 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 58CSibirCgNl for <ipv6@ietfa.amsl.com>; Mon, 14 Oct 2019 14:15:53 -0700 (PDT)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 50AAD12003E for <ipv6@ietf.org>; Mon, 14 Oct 2019 14:15:53 -0700 (PDT)
Received: by mail-oi1-x229.google.com with SMTP id k25so14928259oiw.13 for <ipv6@ietf.org>; Mon, 14 Oct 2019 14:15:53 -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; bh=n+k//rAL+WQyOvlP+y5CQB5wzL3IQS2l6A3LHSbfO2s=; b=DgtswQv6FZo9iECaDLq/C7BxRURMtjK4D9npPdggXu0VGeR82P6Hh6MRdkoenPBg6N a9Qh5wAYPbeWTJmdI0MDCx9g4svoSgy1BMDEE5mXt+t8duix7kzqIJVVWVgyme01lZdW KOi2mAv2+d9/XdFrYZtDwfd7/xXVNH6p9DAcODheRRZj8dk9Oh/Lx22K5OUCXCUF/pGF mN6MZSp8sgViUmi+l9HXpaN/koOB8kAQlouWKWaE/ESKHucRlUzOTZSiXayhAr7BSu/0 AC4SWxoIvy9f1s6rHdubFzQJi2uXwBcqiR8/uJYBqALSzRK7KLUrvYbLy326/i/PGkQN BG4A==
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; bh=n+k//rAL+WQyOvlP+y5CQB5wzL3IQS2l6A3LHSbfO2s=; b=DEogQdSGRRW2marECPIAbpbKFLs/NesDPQUUZK3MpenghtQtEwl+SuxdDVLjpDjng/ +6Wtp2JPiv75h6MhfAcY7Inh8xqokpTG7eIvQJaWM6FvYFr0mcZTAMbgOfEgbp03ALIg fjaus0RaniPBaIRLyHg9FMz3An5HdWsbOIgm87U7qaOO9daUyx3/A2vJa4BkwfsIp5f5 ZgDTnz3u0aXLcHGmztLi5t80fLJutdGkNWBhF26ppQ+S6xEEoc6Bi57CH00IIsOQQsu2 AxqT4BzzEUvs3yIsGf90oLSgx5zlEmcEjQsaOjKChIcw/1nlHEiNUB7RscJpsT1g5p6p crZg==
X-Gm-Message-State: APjAAAVu7vpSa8y2GI/bNejI+MXBkZTUYOGCvGGV37hvRTmWoAt1lKcA IbwBbq7w6Jd/WIiW3neEs75ua5pTRwMZbMwCzZM=
X-Google-Smtp-Source: APXvYqxrGayOqtmYzxYhN0IDxoFipcAXm9Y1p2wMlXXKR54mLLY/3S72HXI8vRyvs/bbtGtQ/MKn8jlyAyCTQogL/XM=
X-Received: by 2002:aca:db09:: with SMTP id s9mr26160668oig.7.1571087752526; Mon, 14 Oct 2019 14:15:52 -0700 (PDT)
MIME-Version: 1.0
References: <156903961333.5092.16807379687598480151@ietfa.amsl.com> <c9702ec2-61d9-66e4-1d2c-d462eaf00f21@gmail.com> <CALx6S37TrL_SsJ3o1FqzskZ4xqyDo8AeHDhXiKpPTd2e8vP_sw@mail.gmail.com>
In-Reply-To: <CALx6S37TrL_SsJ3o1FqzskZ4xqyDo8AeHDhXiKpPTd2e8vP_sw@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 15 Oct 2019 08:15:26 +1100
Message-ID: <CAO42Z2w+ZS55QzbSJ=vEcbWpyWKx2wS+O2QSSwHEOVLz1WQR6g@mail.gmail.com>
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-07.txt
To: Tom Herbert <tom@herbertland.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000667ffc0594e55f08"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/95Xap_7YZ044l5dc6c5ASvzocnQ>
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: Mon, 14 Oct 2019 21:15:56 -0000

Now that tunnelling has been accepted, and that a distinct IP tunnel could
be created for each segment, 1:1, with tunnel/segment heads or tails being
the place where the SRH can be created or transferred, with or without
modification, or over from the previous segment/tunnel, which does comply
with RFC8200 (as tunnel endpoints are IPv6 hosts), there is no functional
need for mid-tunnel anonymous insertion.

So what is the reason to persist with it? It doesn't make sense to me that
people are clinging to an idea that has so many flaws and contradictions to
standard behaviour, when there is a method that works without these flaws
and contradictions.

Determining whether or not to perform deeper packet processing (SRH
processing in this case) on a packet, using the packets' DA, is
conventional, traditional, and implemented in billions of deployed devices,
both hosts and routers.

Contrast that with a device having to purposely ignore literally every
packets' DA that it looks at, to search all of those packets for an SRH to
then determine if it should perform SR processing on it. Unconventional,
non-traditional, and a capability I'd guess is likely to be deployed in way
less than 10 000 devices,  and likely less than 1000.

Not updating SAs after packet modification, and having to purposely
ignoring packets' DAs, is down a rat hole that NAT also lives in.

Regards,
Mark.

On Tue, 15 Oct 2019, 02:54 Tom Herbert, <tom@herbertland.com> wrote:

> On Sat, Oct 12, 2019 at 2:58 PM Brian E Carpenter
> <brian.e.carpenter@gmail.com> wrote:
> >
> > Hi,
> >
> > I'd like to comment on this version. It is in fact a complete rewrite
> compared to
> > its predecessors and I thank the authors for that. The tone is now
> purely technical,
> > and that's a great improvement.
> >
> > It's also, IMHO, accurate in its statements about the relationship with
> RFC 8200.
> > In particular:
> >
> > >    Action 2 inserts an SRH in a packet within the SR domain at a node
> > >    not in the destination address, and inserts more than one SRH in a
> > >    packet.  This does not appear to be permitted by the statements
> > >    quoted above from RFC8200.  However, the restrictions above are not
> > >    applicable within the SR domain.  Every source node participating in
> > >    the SR domain expects SRH insertion, relies on it for services
> > >    provided by the SR domain, correctly processes ICMP errors, and
> > >    according to RFC8200 must process multiple SRH in the same packet.
> >
> > That statement "the restrictions above are not applicable within the SR
> domain"
> > is (it seems to me) a normative statement. It might be even clearer to
> state it
> > as such:
> >   ...the restrictions above SHOULD NOT be applied within the SR domain.
> >
> Brian,
>
> Dissecting this a bit:
>
> "Every source node participating in the SR domain expects SRH insertion"
>
> That is awfully inclusive and seems to be retroactively creating a
> fundamental property of SR domains. Also, no opt out form source? I
> would expect that in most use cases, probably all in deployment today,
> the SR EH is set at the ingress node into the SR domain and describes
> the path to egress. The fact that some intermediate node might insert
> an EH could conceivably be a security issue in such deployments more
> than anything. IMO, if EH is allowed then source nodes should be able
> to opt out, or even better EH insertion should always be opt in from
> the source. If a source node wishes to enforce that no EHs are
> inserted it can do that with AH (assuming that AH were properly
> specified to interact with SRH)..
>
> The draft also states that the source and destination are required to
> be in the same SR domain for EH insertion. This needs to be specified
> as a MUST. The obvious question this raises is: how does an
> intermediate node know that a source and destination are in the SR
> domain? I would infer that the authors are probably assuming that this
> can be done by specifying a prefix for the SR domain or maybe a
> whitelist of addresses? This is easy enough to propose, but on a
> network of even moderate scale I'm not convinced it's manageable. I
> suggest an alternative is for the source node to mark packets for
> which EH insertion is permissible (i.e. the opt in model). This could
> be done for instance by the source setting a null SR header (no SIDs)
> with a flag that indicates EH insert is permitted.
>
> "correctly processes ICMP errors"
>
> That presumes that correct processing of ICMP errors is well defined.
> Consider this scenario:
>
> An intermediate node inserts an SRH with HMAC, a subsequent downstream
> node attempts to verify the HMAC and fails to verify. The downstream
> node sends an ICMP packet back to the source. What is source supposed
> to do with this ICMP error? (note this is just one scenario, the
> general case is how to deal with ICMP errors sent because of error in
> the inserted EH). There is nothing that source host can do within the
> protocol to avoid further occurrences of the error. At best they'll
> log it, but since there's no attribution so now somebody someone needs
> to track down who is inserting the EH-- in a complex network that may
> be non-trivial.
>
> Attribution is critical. One obvious way to address this would be for
> the node inserting the EH to put its address into the SRH, but then
> that reduces the overhead savings of SR EH insertion compared to
> encapsulation to be just eight bytes (destination address in
> encapsulation is same as last address in insert SID list). IMO, it
> would be better to just do encapsulation instead.
>
> Another hole is correct ICMP processing is reflected in:
>
> "The SR domain ingress edge processing the ICMP error SHOULD log the
> error and decrement the ingress edge MTU for traffic traversing the SR
> domain (if it's greater than the IPv6 minimum MTU of 1280 bytes)"
>
> Okay, but what if the source _is_ already at minimum MTU for PMTU?
> Note that SRH can be hundreds of byte and now with insertion there can
> be multiple SRHs of these is a packet, I don't think this is something
> that can be easily dismissed with the typical assumption that all
> networks can just set MTUs large enough.
>
> "However, the restrictions above are not applicable within the SR domain"
>
> I think the wording here is wrong for the intent of the draft. All the
> normative "MUSTs" in RFC8200 and other appropriate standards are
> applicable to _all_ use cases of the protocol. I see no provision in
> RFC8200 that its requirements, like prohibition of EH insertion, are
> conditional based on the environment in which the protocol is
> deployed. So RFC8200 is applicable in SR domains, limited domains, and
> the Internet. IMO, this draft is trying to justify an exception to the
> requirements and should be written as such. Presumably, the exception
> might be palatable if it maintains robustness, interoperability, and
> spirit of requirements of RFC8200.
>
> Tom
>
> > >    the SR domain expects SRH insertion
> > Clearly it's a WG question whether on not we want to put this on the
> standards
> > track. I hope we can discuss it as a technical question. My subsidiary
> > question is: does the description of an SR domain (here and in RFC8402)
> > provide enough security and operational assurance that this SHOULD NOT is
> > safe?
> >
> Hi Brain,
>
>
>
> > Regards
> >    Brian Carpenter
> >j
> > On 21-Sep-19 16:20, internet-drafts@ietf.org wrote:
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > >
> > >
> > >         Title           : Insertion of IPv6 Segment Routing Headers in
> a Controlled Domain
> > >         Authors         : Daniel Voyer
> > >                           Clarence Filsfils
> > >                           Darren Dukes
> > >                           Satoru Matsushima
> > >                           John Leddy
> > >       Filename        :
> draft-voyer-6man-extension-header-insertion-07.txt
> > >       Pages           : 13
> > >       Date            : 2019-09-20
> > >
> > > Abstract:
> > >    Traffic traversing an SR domain is encapsulated in an outer IPv6
> > >    header for its journey through the SR domain.
> > >
> > >    To implement transport services strictly within the SR domain, the
> SR
> > >    domain may require insertion or removal of an SRH after the outer
> > >    IPv6 header of the SR domain.  Any segment within the SRH is
> strictly
> > >    contained within the SR domain.
> > >
> > >    The SR domain always preserves the end-to-end integrity of traffic
> > >    traversing it.  No extension header is manipulated, inserted or
> > >    removed from an inner transported packet.  The packet leaving the SR
> > >    domain is exactly the same (except for the hop-limit update) as the
> > >    packet entering the SR domain.
> > >
> > >    The SR domain is designed with link MTU sufficiently greater than
> the
> > >    MTU at the ingress edge of the SR domain.
> > >
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > >
> https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/
> > >
> > > There are also htmlized versions available at:
> > >
> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-07
> > >
> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion-07
> > >
> > > A diff from the previous version is available at:
> > >
> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> submission
> > > until the htmlized version and diff are available at tools.ietf.org.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > _______________________________________________
> > > I-D-Announce mailing list
> > > I-D-Announce@ietf.org
> > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > Internet-Draft directories: http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> >
> > --------------------------------------------------------------------
> > 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
> --------------------------------------------------------------------
>