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