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 <j...@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 <j...@joelhalpern.com
> > <mailto:j...@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:rob...@raszuk.net
> >     <mailto:rob...@raszuk.net>]
> >      > *Sent:* Thursday, February 17, 2022 11:28 PM
> >      > *To:* Warren Kumari <war...@kumari.net <mailto:war...@kumari.net
> >>
> >      > *Cc:* Ketan Talaulikar <ketant.i...@gmail.com
> >     <mailto:ketant.i...@gmail.com>>; Andrew - IETF
> >      > <andrew-i...@liquid.tech>; Bocci, Matthew (Nokia - GB)
> >      > <matthew.bo...@nokia.com <mailto:matthew.bo...@nokia.com>>;
> >     draft-ietf-bess-srv6-servi...@ietf.org
> >     <mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
> >      > bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>; The IESG
> >     <i...@ietf.org <mailto:i...@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
> >      >
>
>
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to