Re: IPv6 header insertion in a controlled domain
Gyan Mishra <hayabusagsm@gmail.com> Sun, 08 December 2019 15:25 UTC
Return-Path: <hayabusagsm@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 8135C120096 for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 07:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 GQKHoddZTTQV for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 07:25:00 -0800 (PST)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 8097F120047 for <ipv6@ietf.org>; Sun, 8 Dec 2019 07:25:00 -0800 (PST)
Received: by mail-il1-x130.google.com with SMTP id p8so10439205iln.12 for <ipv6@ietf.org>; Sun, 08 Dec 2019 07:25:00 -0800 (PST)
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=to6lD4g660/Az+uiuSh5pSvK5O29KciqKS5KCtZnR/4=; b=GZvHZyiEFnyDtmyVk4hIqkasmfTb3BWdxkypmz8aS2ur0WB+lhuCoe1UhtU7KiVeeC F2EONzYMIR7cn1BI5Qf3tzXDnszFykWGC4A1HtGq+hEjf+DacNMHdheu9f1fSI76EoS1 6D8Ehro5Lu0GwRQSQIV6EWCNogI4jzvxocE8Qtvd3y1wK8FkYLuLX+sOmVFDeJQIb/Dl N57NSno3IF8ZyzWNaPkF2lYZArM1RslxT4OtY6csz5oVf4VA4q04+QYab9gRkbsojC7n TPg82vGi/adBYw2Fy118NZdkcp2URcHW8F5gS+7ecte1ioqP4VWSQXGHRL8EGlNc81JV IidA==
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=to6lD4g660/Az+uiuSh5pSvK5O29KciqKS5KCtZnR/4=; b=fTOpGFP7HMcvaqhuVKStQISQaJCW4lkBRwFjpkGl0EEwCX+R1CXBRGFnR+SCw6MrUD BtfENEU/dET7gsjVO9VB5QwhqQrMus91P1zkvFE2TwO+gGSYsiUGUiUglddSBoytqK3+ wUBRj7BTeMmpT/460Hfvk+ynoo+t5bbqfQTnGC+ikJ1sWBPOnUP7ejmbog3ODTl/fkKy QUJ1Klz0I5jUTRFu11nZrhZxwn2M1b4aJisF1GFdkHVMPrSI3LpL0gTQHFZabC1jpuzl 5rePVxo3j1zxlg7mNe0mCI3Vb3uJpF4Qn1EqCi6BTQ9Nt03ZqSdHyoLSSu1lIUjrjVOL gOBg==
X-Gm-Message-State: APjAAAULA0OBhOFbwnMrpTZg6iEk1mvUP6yEmlwyP+EmZcQBaVfdHt52 KA4k1PT2nXw3EAFHNC+6X7p3dUBEDJOFV/De0SY=
X-Google-Smtp-Source: APXvYqyb6bXUcOdX8eug7hsYtfvDDpPnsLiJ71Zxl8y+l0sR+HAOhAIqiUFqLanA0UXd8DhQRB65j4/uedIwTdFvcc0=
X-Received: by 2002:a92:4095:: with SMTP id d21mr23466877ill.158.1575818699645; Sun, 08 Dec 2019 07:24:59 -0800 (PST)
MIME-Version: 1.0
References: <CALx6S3588ja9AZzBQ0dqwx0j-ki6A5tusye+odQKPyAyF+hEww@mail.gmail.com> <10E890EA-3278-44EE-881E-EBC91D419587@employees.org> <88287cb0-c0c3-f990-4dd7-338df87c7fb2@joelhalpern.com> <4E76C386-FB1E-4E48-814D-BB626466BEE3@employees.org> <CAO42Z2ze7tmkGh=E-YrPuJHMeD8V6EuxgjjaJ33iz+Ms3abNsA@mail.gmail.com> <ED9B7C60-ACDE-4107-A121-AE2DAEA6B640@employees.org>
In-Reply-To: <ED9B7C60-ACDE-4107-A121-AE2DAEA6B640@employees.org>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sun, 08 Dec 2019 10:24:49 -0500
Message-ID: <CABNhwV0EGiMaX0Qkyk+_zqZfiaAS_RP_ewVEctgdSnMuJ3MBPw@mail.gmail.com>
Subject: Re: IPv6 header insertion in a controlled domain
To: otroan@employees.org
Cc: 6man WG <ipv6@ietf.org>, Mark Smith <markzzzsmith@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d2a915059932e1ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/F6bKpiK_5GEVfMRhxVhjHdq86Go>
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: Sun, 08 Dec 2019 15:25:02 -0000
On Sun, Dec 8, 2019 at 4:25 AM <otroan@employees.org> wrote: > Mark, > > [...] > [renamed thread] > > > Take an example of 3 routers A, B and C that is under the same control. > > Traffic travels from left to right. > > > > A -- B -- C > > > > A has a tunnel to C using ULA source and destination. > > A packet ingresses on A, is encapsulated and forwarded towards C. > > A has for reasons unknown to us outsourced a function to B. Where B > insert an extension header in the packet originated by A. > > C is also in on the game, being a tunnel end-point, removing the > encapsulating header and extension header. > > > > If you can leave the nuances of SR and the whatever they propose on the > shelf for a minute. > > > > Do you agree in principle that this approach of "header insertion in a > controlled domain" can be made to work, > > and should be indiscernible from A inserting the extension header itself? > > Yes, there are obviously many ways of skinning this cat. > In this thread I don't want to try solve whatever problem the EH insertion > camp wants solved. I don't think I understand it well enough. > And I'm unconvinced the 6man group in general understands the underlaying > routing problems leading to the proposed solution. > What I was interested in exploring in this thread was if we could reach > agreement that there in principle is a safe way of doing header insertion. > > In my simple example above. > Do you agree that in a controlled distributed system there is no > perceivable difference between node A inserting the header or node B doing > it? > Conceptually you could think of it as a tunnel with muliple endpoints > (although that's a bit hard to visualize ;-)). > > Can we agree that inserting headers and changing the packet size among > participating nodes in a distributed system is not inherently unsafe? > As far as I can think of the only complication to be considered is that > node A must be aware of packet size changes when doing PMTU estimation. > (typically though in these types of networks, one simply declares that > "MTU must be well managed. i.e. large enough". Ole I think the in flight eh insertion done on the node doing the encapsulation node A is safer from a security perspective then an intermediate node adding a eh header without encapsulation. I think even though you add an encapsulation but if the node doing the encapsulation is not the one adding the eh header it’s no different in my opinion then the node A not doing an encapsulation at all which was proposed initially by Spring. So we have to enforce that the EH insertion is only done by the node performing the encapsulation. With SRv6 I don’t think there would be a case where intermediate node B is doing the EH insertion without encapsulation as well. We should verify that with Spring and even if they are doing do we should ensure they add an encapsulation as well for each instance. See below: >From a SR perspective this is what the flow would look like in a controlled SR domain like a SP core which is one of the primary use cases for SRv6. A(CE) - B(PE) - C(P) - D(P) - E (PE) - Z(CE) Each node in the SR domain has a /64 which is the SID locator in the SID list. The main goal of the SRH header insertion is to source route the packer Along the defined traffic engineered path hop by hop. At each hop along the path the SRH is processed PSSI (per service segment instruction) SID locator /64 defined on each node in the SR domain is copied to the DA of each of the intermediate nodes along the path. This allows the flow to be hop by hop source routed. A customer originating flow A & B have the identical VRF PE-CE relationship as with MPLS L3 vpn VRF with routing protocol enabled B ingress of SR domain adds encapsulation and SRH routing header type 4. C performs PSSI and copies SR SID locator /64 to destination address in outer IP header D Egress P performs PSP Penultimate segment pop and removes outer header encapsulation and EH inserted at node A E egress PE Performs USP Ultimate segment pop if explicit null is enabled and removes the encapsulation and EH header. This node pops all remaining encapsulations such as L3 VPN AFIs identical function of MPLS PE ( end node in the SR domain) Packet is forwarded natively to the CE Z CE - receives the native IPv4 or IPv6 packet In all cases the originating PE node of the SR domain is the node that added the outer header encapsulation and SRH EH header. With SRv6 you would never have node B adding EH header unless special case below and then it would be also adding an encapsulation as well. There maybe cases where Ti-LFA is enabled along the SRv6 path for node protection. In those cases there would be an additional encapsulation and SRH header header at the point of local repair(PLR). That additional encapsulation would get removed prior to reaching node D in example above. There also maybe cases of tunnel stitching use where you may have additional encapsulations added as well along with SRH header which would follow the same process as above. I think as long as Spring adheres to only allowing the node performing the encapsulation to be allowed to add the SRH header then I think we should be safe and also not in violation of RFC 8200. Also no security issues with in flight eh insertion is now eliminated. Gyan > > Cheers, > Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Gyan S. Mishra IT Network Engineering & Technology Verizon Communications Inc. (VZ) 13101 Columbia Pike FDC1 3rd Floor Silver Spring, MD 20904 United States Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com www.linkedin.com/in/networking-technologies-consultant
- Network Programming - Penultimate Segment Popping Ron Bonica
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… Darren Dukes (ddukes)
- RE: Network Programming - Penultimate Segment Pop… Ron Bonica
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… otroan
- RE: Network Programming - Penultimate Segment Pop… Ron Bonica
- Re: Network Programming - Penultimate Segment Pop… otroan
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- We don't seem to be following our processes (Re: … Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Tom Herbert
- RE: We don't seem to be following our processes (… Ron Bonica
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Enno Rey
- Re: We don't seem to be following our processes (… Enno Rey
- RE: We don't seem to be following our processes (… Ron Bonica
- Re: We don't seem to be following our processes (… Bob Hinden
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Sander Steffann
- Re: We don't seem to be following our processes (… Alexandre Petrescu
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: We don't seem to be following our processes (… Bob Hinden
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: We don't seem to be following our processes (… otroan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… otroan
- RE: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… otroan
- RE: [spring] We don't seem to be following our pr… Ron Bonica
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… Darren Dukes (ddukes)
- Re: We don't seem to be following our processes (… Fernando Gont
- RE: Network Programming - Penultimate Segment Pop… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Ole Troan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: We don't seem to be following our processes (… Ole Troan
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Separating issues (was Re: [spring] We don't seem… Suresh Krishnan
- RE: Separating issues (was Re: [spring] We don't … Ketan Talaulikar (ketant)
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Mark Smith
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… otroan
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Alexandre Petrescu
- Re: Network Programming - Penultimate Segment Pop… Darren Dukes (ddukes)
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Darren Dukes (ddukes)
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: Network Programming - Penultimate Segment Pop… Tom Herbert
- Re: [spring] Network Programming - Penultimate Se… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: We don't seem to be following our processes (… Mark Smith
- IPv6 header insertion in a controlled domain otroan
- IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Sander Steffann
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Joel M. Halpern
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Tom Herbert
- Re: IPv6 header insertion in a controlled domain jmh.direct@joelhalpern.com
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain otroan
- Re: We don't seem to be following our processes (… Alexandre Petrescu
- Re: IPv6 header insertion in a controlled domain Sander Steffann
- Re: IPv6 header insertion in a controlled domain Brian E Carpenter
- Re: IPv6 header insertion in a controlled domain Warren Kumari
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- RE: We don't seem to be following our processes (… Ron Bonica
- RE: IPv6 header insertion in a controlled domain Ron Bonica
- Re: IPv6 header insertion in a controlled domain Sander Steffann
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- RE: IPv6 header insertion in a controlled domain Ron Bonica
- Re: IPv6 header insertion in a controlled domain otroan
- RE: [spring] We don't seem to be following our pr… bruno.decraene
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- Re: IPv6 header insertion in a controlled domain Tom Herbert
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- RE: IPv6 header insertion in a controlled domain Ron Bonica
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- Re: topics to circulate Alexandre Petrescu
- Re: topics to circulate Gyan Mishra
- Re: topics to circulate Erik Kline
- Re: topics to circulate Alexandre Petrescu
- Re: topics to circulate Alexandre Petrescu
- Re: IPv6 header insertion in a controlled domain Alexandre Petrescu
- Re: IPv6 header insertion in a controlled domain Alexandre Petrescu