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
>
> On Thu, Feb 17, 2022 at 4:14 PM Warren Kumari <war...@kumari.net
<mailto:war...@kumari.net>
> <mailto:war...@kumari.net <mailto:war...@kumari.net>>> wrote:
>
> On Sun, Feb 13, 2022 at 11:54 PM Ketan Talaulikar
> <ketant.i...@gmail.com <mailto:ketant.i...@gmail.com>
<mailto:ketant.i...@gmail.com <mailto:ketant.i...@gmail.com>>> wrote:
>
> Hi Warren/All,
>
> This draft specifies broadly two types of BGP Services
over SRv6:
>
> A) VPN Services (L3VPN & EVPN) - Sec 5.1, 5.2 & 6
>
> B) Global Internet Services - Sec 5.3, 5.4
>
> As explained by my co-author Robert, the operations and
> mechanisms for VPN services are similar to what we've had
with
> MPLS. I believe we are all on the same page on this one
based on
> the discussions between Andrew and Robert and that there
is no
> new concern as far as (A).
>
> Actually, no, I don't think that we are -- if I, as an attacker,
> somehow know that VPN x uses MPLS labels Y, that's
interesting, but
> not particularly valuable -- because of the "fail closed"
nature of
> MPLS (it's a different protocol, and needs explicit and
intentional
> action to enable on an interface) it's really hard for me to
> "inject" an MPLS packet and route it into your network. With
SRv6,
> if the SIDs leak, I can construct a normal v6 packet and route it
> towards you. Yes, handwave handwave the RFCs say that you MUST
> filter at your edges and that the filtering MUST always be
perfect
> handwave limited domain handwave -- but it's putting a large
amount
> of faith in operator perfection.
>
> Also, if I, as an attacker get access to a "server" in the
provider
> network (noc workstation, billing machine, random admin PC, etc),
> with MPLS it's very unlikely to be part of the MPLS domain,
but an
> SRv6 domain is much more likely to be "squishy" and more
likely to
> encompass parts of the "enterprise" type systems.
>
> W
>
> Now (B) does bring in filtering aspects (as mentioned in the
> security considerations) to ensure that the SRv6 block
that is
> meant for use internal to the operator's network (i.e. SR
> domain) does not get leaked/advertised out from the default
> table on the Internet Border Router (IBR) over to an eBGP
peer.
> This is similar to the precautions that operators take
today to
> prevent their infrastructure addresses from being leaked
to the
> Internet. The filters in BGP are also accompanied by ACLs
at the
> IBRs to prevent traffic destined for those infrastructure IPs
> from entering into the operator network. This is the same
in the
> case of SRv6 as well.
>
> I hope that clarifies and we can update the text to
convey these
> aspects better.
>
> Thanks,
>
> Ketan
>
> On Sun, Feb 13, 2022 at 12:21 AM Andrew - IETF
> <andrew-i...@liquid.tech <mailto:andrew-i...@liquid.tech
<mailto:andrew-i...@liquid.tech>>> wrote:
>
> Hi Robert,
>
> 5.3 Also opens the door to SAFI 1 – since you can v6
over v4
> using AFI 1 / SAFI 1 using what is defined in
RFC8950, in
> fact, it is explicit.
>
> Section 5.3 is titled Global IPv4 over SRv6 core – this
> correlates with the example in section 6.1 of RFC8950 –
> which states:
>
> The extensions defined in this document may be
used as
> discussed in
>
> [RFC5565
> <https://datatracker.ietf.org/doc/html/rfc5565
<https://datatracker.ietf.org/doc/html/rfc5565>>] for the
> interconnection of IPv4 islands over an IPv6
>
> backbone. In this application, Address Family Border
> Routers (AFBRs;
>
> as defined in [RFC4925
> <https://datatracker.ietf.org/doc/html/rfc4925
<https://datatracker.ietf.org/doc/html/rfc4925>>]) advertise
> IPv4 NLRI in the MP_REACH_NLRI
>
> along with an IPv6 next hop.
>
> The MP_REACH_NLRI is encoded with:
>
> * AFI = 1
>
> * SAFI = 1
>
> * Length of Next Hop Address field = 16 (or 32)
>
> * Next Hop Address = IPv6 address of the next hop
>
> * NLRI = IPv4 routes
>
> During BGP Capability Advertisement, the PE routers
> would include the
>
> following fields in the Capabilities Optional
Parameter:
>
> * Capability Code set to "Extended Next Hop
Encoding"
>
> * Capability Value containing <NLRI AFI=1, NLRI
SAFI=1,
> Nexthop
>
> AFI=2>
>
> As I say, if you were to remove the references to
global and
> 5.3/5.4 which explicitly reference it and bring SAFI
1 into
> play – there would be far less concern from my side,
I can’t
> speak for anyone else, but that would be my feeling
>
> Thanks
>
> Andrew
>
> *From:*Robert Raszuk <rob...@raszuk.net
<mailto:rob...@raszuk.net>
> <mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>>>
> *Sent:* Saturday, February 12, 2022 9:37 PM
> *To:* Andrew - IETF <andrew-i...@liquid.tech
> <mailto:andrew-i...@liquid.tech
<mailto:andrew-i...@liquid.tech>>>
> *Cc:* Warren Kumari <war...@kumari.net
<mailto:war...@kumari.net>
> <mailto:war...@kumari.net
<mailto:war...@kumari.net>>>; Bocci, Matthew (Nokia - GB)
> <matthew.bo...@nokia.com
<mailto:matthew.bo...@nokia.com> <mailto:matthew.bo...@nokia.com
<mailto:matthew.bo...@nokia.com>>>;
> draft-ietf-bess-srv6-servi...@ietf.org
<mailto:draft-ietf-bess-srv6-servi...@ietf.org>
> <mailto:draft-ietf-bess-srv6-servi...@ietf.org
<mailto:draft-ietf-bess-srv6-servi...@ietf.org>>;
> bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>
<mailto:bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>>; The IESG
> <i...@ietf.org <mailto:i...@ietf.org>
<mailto:i...@ietf.org <mailto:i...@ietf.org>>>; BESS <bess@ietf.org
<mailto:bess@ietf.org>
> <mailto: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 Andrew,
>
> When I read Warren's note Iooked at this text
from section 2
> which says:
>
> - - -
>
> The SRv6 Service TLVs are defined as two new TLVs
of the
> BGP Prefix-
> SID Attribute to achieve signaling of SRv6 SIDs
for L3
> and L2
> services.
>
> o SRv6 L3 Service TLV: This TLV encodes Service SID
> information for
> SRv6 based L3 services. It corresponds to the
equivalent
> functionality provided by an MPLS Label when
received
> with a Layer
> 3 service route as defined in [RFC4364] [RFC4659]
> [RFC8950]
> [RFC9136]. Some SRv6 Endpoint behaviors which
MAY be
> encoded, but
> not limited to, are End.DX4, End.DT4, End.DX6,
> End.DT6, etc.
>
> o SRv6 L2 Service TLV: This TLV encodes Service SID
> information for
> SRv6 based L2 services. It corresponds to the
equivalent
> functionality provided by an MPLS Label1 for
Ethernet
> VPN (EVPN)
> Route-Types as defined in [RFC7432]. Some SRv6
> Endpoint behaviors
> which MAY be encoded, but not limited to, are
> End.DX2, End.DX2V,
> End.DT2U, End.DT2M etc.
>
> When an egress PE is enabled for BGP Services
over SRv6
> data-plane,
> it signals one or more SRv6 Service SIDs enclosed in
> SRv6 Service
> TLV(s) within the BGP Prefix-SID Attribute
attached to
> MP-BGP NLRIs
> defined in [RFC4760] [RFC4659] [RFC8950]
[RFC7432] [RFC4364]
> [RFC9136] where applicable as described in
Section 5 and
> Section 6.
>
> The support for BGP Multicast VPN (MVPN) Services
> [RFC6513] with SRv6
> is outside the scope of this document.
>
> - - -
>
> This limits the overlay signalling to non global SAFIs
> mainly SAFI 128 and SAFI 70.
>
> To your note SAFI 4 is private and never exchanged in the
> wild. Also SAFI 2 is multicast which is out of scope
of this
> draft.
>
> The only thing which we need to sync on is indeed section
> 5.4 and use of global IPv6 AFI 2 & SAFI 1
>
> Many thx,
>
> R.
>
> On Sat, Feb 12, 2022 at 7:11 PM Andrew - IETF
> <andrew-i...@liquid.tech
<mailto:andrew-i...@liquid.tech <mailto:andrew-i...@liquid.tech>>>
> wrote:
>
> Robert,
>
> I have to say that I have very similar readings
on parts
> of the draft.
>
> Let’s look at it –
>
> 5.1 uses the IPv4-VPN NLRI – That would seem to
indicate
> AFI 1 / SAFI 4
>
> 5.2 – Uses AFI 2 / SAFI 4 from my reading
>
> 5.3 – According to RFC8950 – allows advertisement
over
> SAFI 1, 2 or 4
>
> 5.4 – To my reading – very much refers to AFI 2 /
SAFI 1.
>
> I would agree if this document limited itself to
5.1 and
> 5.2 – it doesn’t – and therefore I have to agree with
> the thoughts expressed in Warrens Discuss. If I am
> wrong about 5.3 and 5.4, let’s chat and help me
> understand this better, and then lets potentially
see if
> we can work up some wording that would clarify
this if
> that is what is required.
>
> Thanks
>
> Andrew
>
> *From:*iesg <iesg-boun...@ietf.org
<mailto:iesg-boun...@ietf.org>
> <mailto:iesg-boun...@ietf.org
<mailto:iesg-boun...@ietf.org>>> *On Behalf Of *Robert Raszuk
> *Sent:* Saturday, February 12, 2022 8:26 PM
> *To:* Warren Kumari <war...@kumari.net
<mailto:war...@kumari.net>
> <mailto:war...@kumari.net
<mailto:war...@kumari.net>>>
> *Cc:* Bocci, Matthew (Nokia - GB)
> <matthew.bo...@nokia.com
<mailto:matthew.bo...@nokia.com>
> <mailto:matthew.bo...@nokia.com
<mailto:matthew.bo...@nokia.com>>>;
> draft-ietf-bess-srv6-servi...@ietf.org
<mailto:draft-ietf-bess-srv6-servi...@ietf.org>
> <mailto:draft-ietf-bess-srv6-servi...@ietf.org
<mailto:draft-ietf-bess-srv6-servi...@ietf.org>>;
> bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>
<mailto:bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>>; The
> IESG <i...@ietf.org <mailto:i...@ietf.org>
<mailto:i...@ietf.org <mailto:i...@ietf.org>>>; BESS
> <bess@ietf.org <mailto:bess@ietf.org>
<mailto: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,
>
> Thank you for your Discuss. But before we start
> discussing it perhaps it would be good to align
on what
> this document really defines as I am sensing from
your
> description there can be some disconnect (modulo some
> text may be indeed misleading in the draft).
>
> You said:
>
> > However, we all know that BGP leaks happen --
and when they do, the SID’s
> > contained in the leak will be logged by various
systems and hence available to
> > the public into perpetuity.
>
> I think the term BGP is used here a bit too broadly.
>
> Leaks do happen but only within global AFI/SAFIs.
This
> draft defines extensions for L3VPN and L2VPNs SAFIs
> which are not used to peer outside of a domain,
> collection of domains under same administration +
> of course inter-as also could happen.
>
> With that being said I do not see risk that due to
> leaking there could be a situation where customer
> networks are exposed in any way externally - leaving
> alone that to even get at the transport level to the
> customer facing PE is also filtered and never allowed
> from outside. But this is out of scope of this
document
> as here the focus is not on underlay but overlay.
>
> Now when I re-read this I see why there is a little
> piece perhaps misleading. The draft makes a claim
that
> it is applicable to RFC8950 which defines use of NHv6
> with both unicast and VPN AFs. That needs to be made
> clear that it is applicable to the latter only.
If other
> co-authors believe this is applicable to the
former your
> DISCUSS section would indeed be valid.
>
> Many thx,
>
> R.
>
> On Sat, Feb 12, 2022 at 12:05 AM Warren Kumari via
> Datatracker <nore...@ietf.org
<mailto:nore...@ietf.org> <mailto:nore...@ietf.org
<mailto:nore...@ietf.org>>>
> wrote:
>
> Warren Kumari has entered the following ballot
> position for
> draft-ietf-bess-srv6-services-10: Discuss
>
> When responding, please keep the subject line
intact
> and reply to all
> email addresses included in the To and CC lines.
> (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/blog/handling-iesg-ballot-positions/
<https://www.ietf.org/blog/handling-iesg-ballot-positions/>
>
<https://www.ietf.org/blog/handling-iesg-ballot-positions
<https://www.ietf.org/blog/handling-iesg-ballot-positions>>
> for more information about how to handle
DISCUSS and
> COMMENT positions.
>
>
> The document, along with other ballot
positions, can
> be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>
>
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services>>
>
>
>
>
----------------------------------------------------------------------
> DISCUSS:
>
----------------------------------------------------------------------
>
> The Security Considerations section says: "The
> service flows between PE routers
> using SRv6 SIDs advertised via BGP are
expected to
> be limited within the
> trusted SR domain (e.g., within a single AS or
> between multiple ASes within a
> single provider network). Precaution should be
> taken to ensure that the BGP
> service information (including associated
SRv6 SID)
> advertised via BGP sessions
> are limited to peers within this trusted SR
domain."
> This is related to (from
> RFC8402): "Therefore, by default, the explicit
> routing information MUST NOT be
> leaked through the boundaries of the administered
> domain."
>
> However, we all know that BGP leaks happen -- and
> when they do, the SID’s
> contained in the leak will be logged by various
> systems and hence available to
> the public into perpetuity.
>
> While the document states that border filtering
> should protect against traffic
> injection, this does not cover the case of
internal
> compromise. Sure, there is
> the argument that once there is an internally
> compromised system, all bets are
> off -- but with this, an attacker that knows the
> SIDs in e.g inject traffic
> into a VPN. This seems to me to significantly
expand
> the attack surface to
> include the customer's networks too.
>
> Not only does an operator have to ensure that BGP
> leaks never occur, they have
> to then ensure that at no point can there be any
> filter lapses at any border
> node, and be able to guarantee the security
of every
> device, server and machine
> within the domain in order for a secure
posture to
> be maintained. Simply saying
> that precautions should be taken to make sure
that
> route leak don't occur, when
> the consequences of doing so are a: severe and b:
> hard to recover from seems to
> not really cover it. In addition, it seems
that the
> blast radius from a missing
> ACL seems much larger if it allows injections.
>
>
>
----------------------------------------------------------------------
> COMMENT:
>
----------------------------------------------------------------------
>
> I'm still reviewing the document, but wanted
to get
> an initial ballot in, so
> that we could start discussing it. Hopefully
someone
> can help my understand how
> this doesn't expand the consequences of a BGP
leak.
>
>
> --
>
> The computing scientist’s main challenge is not to get
confused by the
> complexities of his own making.
> -- E. W. Dijkstra
>
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org <mailto:BESS@ietf.org>
> https://www.ietf.org/mailman/listinfo/bess
<https://www.ietf.org/mailman/listinfo/bess>
