Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

Robert Raszuk <robert@raszuk.net> Thu, 17 February 2022 16:18 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6213A0AA8 for <bess@ietfa.amsl.com>; Thu, 17 Feb 2022 08:18:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 LTYmk5xBvrnh for <bess@ietfa.amsl.com>; Thu, 17 Feb 2022 08:18:25 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 936253A0AAF for <bess@ietf.org>; Thu, 17 Feb 2022 08:18:25 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id w4so6859714vsq.1 for <bess@ietf.org>; Thu, 17 Feb 2022 08:18:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fCe+Lc1YUNXU1CABRyqnZVG3cr2lC5T4hiN/jkHu6tU=; b=b9XWoCsyyaWjOdKO9eSmd8skaF1CTyIe8J9j5VPLPlFlAL0HdW12bmJC7kZrRODzxP nKJfK6r/zBwIVpUMhDpxnI1wuKjOqzOZDIaaXqdP2xFT3FI/pcXlOKkB0OK2cyEB/WWH AE5dydipqlgq2TwzQmRe8cf+uVNm4GS7UQzVR3CLR7mZwta/SegzD2NTaDMjssrFTh8d h2LFO9zFmhisbdfuQqKN+IJYVJ3DtOsn57cMqCWVARibSW/Tmz8rPaiuOpcBsdZGnFQN XQflLg/Irv1HRBBgLre7OJ/PYruw6dNRbdFkIw6KH2+7Md7xMe0lvGVIfFeQg2yyt40A mL2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fCe+Lc1YUNXU1CABRyqnZVG3cr2lC5T4hiN/jkHu6tU=; b=FwgotzoJ3YcMM7w2meZjdWWPjtDWq4N8fIBpuT2oQV5D9vQ8/Z9L2gIpweC6m6+j+Y Tx4W/gh44qgJnmacl4wDRbMyc3Q1leOsKbptzuTgCJG55eQUmPeupdB8ub0IeSp7uJMI 2dQYWbBHI6Ia4/86we3mYc90TDoTflmEAeE7bK27miKBYmrRNdN0BPIF9J5T+7PpsMLr RcqMSJTJDUGOOYIQQZ26E6D+NWzPCeLBQ82nDFT4p3T8E6UdjsyvBhvcPKjE2aoQzAC2 RRltsAu1SPdAKKdWNGynqzyLRkKkBl3SNL9P5DmVdzhOF/kVgjD5fSzJdXhyEiaGyJt1 J+wQ==
X-Gm-Message-State: AOAM532r4E80/f7Di772sbNiaMaF2yAVH4upADUpPKtR/vS6nhzNd8uc HMfacZVzuUl9bJbuc0EEZZJkVBqc3EIkvZzOjWaOTQ==
X-Google-Smtp-Source: ABdhPJzoh87EcCwyrBoUhUHkLJ1UPXK2/gBtT1/jjkZreSWJ38oO9nAkWg/sVqYVolC6Olb+F+Lfm2e7qwoYJfKQcAQ=
X-Received: by 2002:a67:c00a:0:b0:31a:fc72:451d with SMTP id v10-20020a67c00a000000b0031afc72451dmr1537375vsi.38.1645114704171; Thu, 17 Feb 2022 08:18:24 -0800 (PST)
MIME-Version: 1.0
References: <164462070317.8057.6829026572175337017@ietfa.amsl.com> <CAOj+MMFtGVoaoj-L5Wv2yZz+HpQ3JLehvtBHtxrfG0-wCfko8g@mail.gmail.com> <AM7PR03MB64511292D62F62956411ED67EE319@AM7PR03MB6451.eurprd03.prod.outlook.com> <CAOj+MMFA3jq7XOB4nB8A2t+A2iuty25NMB+9x5NTHTeVdcz9+Q@mail.gmail.com> <AM7PR03MB64515E34B0CD23E44D7EB83BEE319@AM7PR03MB6451.eurprd03.prod.outlook.com> <CAH6gdPwgkfGHJyD9p4tAzGTTy4-vNRhNdzgTA=LgzxzPbZp7zw@mail.gmail.com> <CAHw9_iKmMgKrNv_yVX3fp8gEZi4_ZEtUPLC3ycXU+H3uaoqfVg@mail.gmail.com> <CAOj+MMGvt-h4U4tbOHg8fSGyT_A8tdws8J747-D+-RjOc0dtkA@mail.gmail.com> <de47b5ed7bf64831906862e30e84dffd@huawei.com> <8e022f7b-f710-a2f7-0171-4a9a1d65b501@joelhalpern.com> <CAOj+MMEcA2hpaskPmcZjsm7mX9b4jHF0n3kakbG0LS+BzxJ9CQ@mail.gmail.com> <eaf13c98-1c2b-1946-cad5-6588c4cbd1e3@joelhalpern.com>
In-Reply-To: <eaf13c98-1c2b-1946-cad5-6588c4cbd1e3@joelhalpern.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 17 Feb 2022 17:18:13 +0100
Message-ID: <CAOj+MMFieCKRJEf9BwR5nnOYSzKj_7tAawZ=c8u7uuw2V7hJhQ@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Zhuangshunwan <zhuangshunwan=40huawei.com@dmarc.ietf.org>, "draft-ietf-bess-srv6-services@ietf.org" <draft-ietf-bess-srv6-services@ietf.org>, BESS <bess@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008eaab105d8391da0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/tZFm2acPqFj6r9iA6mq8GAHsKIk>
Subject: Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Feb 2022 16:18:31 -0000

Joel,

There was a lot of effort by various vendors put in place to help automate
protection of the domain from getting any external packet to the
infrastructure addresses.

Typically I have seen two models in SPs:

* automatic ACL protection at the data plane for all infra targets
(sometimes with exceptions of ICMP)

* putting Internet into a VPN itself hence limiting to what comes from
Internet stays in the special VPN dedicated for it.

I have not seen much individual protection done at the L2 or L3 VPNs PEs to
selectively decapsulate. But it could be done too.

However all of this is about transport layer, while this draft is mainly
about service layer so to me this is out of topic if you see the layer
decoupling.

BESS :),
Robert.


On Thu, Feb 17, 2022 at 5:11 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> I would have to dig for it, but there is general guidance that nodes
> should not decapsulate IP tunnels that they don't know about.  (There
> are exceptions, such as LISP.  But neither GRE nor MPLS in UDP have such
> exceptions.)  Conceptually, SRv6 introduces a generic exception for SRv6
> SIDs within the limited domain.  But still says to check that the packet
> you are receiving at least claims to be from within the limited domain.
>
> This has nothing to do with sr-policy.
>
> Yours,
> Joel
>
> On 2/17/2022 11:06 AM, Robert Raszuk wrote:
> > Joel,
> >
> > But we are back to per src policy then right ?
> >
> > Frankly I never saw such a policy on egress PEs and I did see L3VPNs or
> > L2VPNs running over IP. The protection is applied on ingress you your
> > domain.
> >
> > Thx,
> > R.
> >
> >
> > On Thu, Feb 17, 2022 at 5:03 PM Joel M. Halpern <jmh@joelhalpern.com
> > <mailto:jmh@joelhalpern.com>> wrote:
> >
> >     I would presume that the general policy (which does not apply to
> SRv6)
> >     that nodes should not decapsulate  tunnel packets without
> configuration
> >     or special exemption would mean that an arbitrary MPLS node will not
> >     decapsualte a GRE packet and process its MPLS content.  Otherwise,
> all
> >     tunnels become major security risks.
> >
> >     Yours,
> >     Joel
> >
> >     On 2/17/2022 10:41 AM, Zhuangshunwan wrote:
> >      > Hi all,
> >      >
> >      > +1 for Robert.
> >      >
> >      > Yes, especially when MPLS in GRE or MPLS in UDP is deployed,
> packets
> >      > carrying MPLS labels can traverse all IP-reachable networks and
> >     reach
> >      > remote PEs.
> >      >
> >      > BR,
> >      >
> >      > Shunwan
>
>      >
> >      > *From:*Robert Raszuk [mailto:robert@raszuk.net
> >     <mailto:robert@raszuk.net>]
> >      > *Sent:* Thursday, February 17, 2022 11:28 PM
> >      > *To:* Warren Kumari <warren@kumari.net <mailto:warren@kumari.net
> >>
> >      > *Cc:* Ketan Talaulikar <ketant.ietf@gmail.com
> >     <mailto:ketant.ietf@gmail.com>>; Andrew - IETF
> >      > <andrew-ietf@liquid.tech>; Bocci, Matthew (Nokia - GB)
> >      > <matthew.bocci@nokia.com <mailto:matthew.bocci@nokia.com>>;
> >     draft-ietf-bess-srv6-services@ietf.org
> >     <mailto:draft-ietf-bess-srv6-services@ietf.org>;
> >      > bess-chairs@ietf.org <mailto:bess-chairs@ietf.org>; The IESG
> >     <iesg@ietf.org <mailto:iesg@ietf.org>>; BESS <bess@ietf.org
> >     <mailto:bess@ietf.org>>
> >      > *Subject:* Re: Warren Kumari's Discuss on
> >      > draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
> >      >
> >      > Hi Warren,
> >      >
> >      > I am very sorry but I see folks are completely mixing transport
> >     layer
> >      > and service layer.
> >      >
> >      > In RFC4364 you can use MPLS label for service demux and IP
> >     transport to
> >      > get to remote egress PE via any IP network including Internet.
> >      >
> >      > There is nothing in L3VPNs like enabling MPLS on interface as
> >     mandatory
> >      > prerequisite. Yes many folks are confused about this and I see
> >     the same
> >      > confusion here. The service plane is completely separate from
> >     transport
> >      > layer from day one.
> >      >
> >      > Kind regards,
> >      >
> >      > Robert
> >      >
>
>