Mailing List Archive

MPLS to Customer (Option B) / Multiple VRFs on CPEs
Hi All,

I know this has been discussed before (more on the NANOG list) but
what are people doing regarding MPLS down to the CPE?

Even though we own our CPEs and customers typically don't have access
to them (or perhaps restricted show commands) it is a security concern
that customers can send labelled packets back into the network if we
enable MPLS on the CE facing interface on our PE. There is also the
concern of route injection but I believe that risk can be removed by
enabling MD5 on BGP and LDP sessions between CE and PE.

(i) My first idea was uRPF, on the 12000 routers it seems that uRFP
can inspect MPLS;

From : http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/srpf_gsr.html
"All Layer 2 encapsulation and transport types are supported,
including ATM AAL5, ATM cell relay, Ethernet (VLAN and port modes),
Frame Relay, HDLC, and PPP over MPLS; for more information, refer to
Any Transport over MPLS."
...
"Although the Unicast RPF in Strict Mode feature filters only IPv4
packets in IP or MPLS traffic, you can configure IOS software features
that manage other traffic on the same interface, such as IP
forwarding, MPLS features, Frame Relay switching, ATM switching, and
Any Transport over ATM (AToM) connections. However, Unicast RPF
filtering is only applied to incoming traffic on IP routing interfaces
and not on packets processed by Frame Relay or ATM switching or
transmitted over AToM pseudowire commendations."

We aren't using 12000 though; At the access layer we're using
ME3600/ME3800/6500/7600/ASR1K and we're looking at 6880-X to remove
the smaller access layer 6504/6505/7604/7607 type chassis. I can't
find any indication that any of those can support MPLS in uRPF so I
think that idea is useless unless someone else can show me some
contradictory information?

(ii) My second idea was label value range restrictions

Since the average CPE may have 3-5 VRFs on it with say 10 routes in
each we could perhaps fiddle with the label allocation rules by
setting 1000-1999 to be the usable range at PoP A, and 2000-2999 at
PoP B and so on. We can restrict the routes that enter the LFIB at the
PEs and which ones get labels allocated to them. Techniques like this
reduce the surface area of potential attack and make it difficult to
send in packets with a valid label (or label stack) but they seem more
like security through obscurity to me.

(iii) Additional options...

I'm all ears! Is anyone running MPLS to the customer rather than
multiple option A perings to each CPE? When we do large roll outs of
1000 CPEs with each CPE having a minimum of 3 and maximum of ~10 VRFs
we end up having thousands of peerings. MPLS to the customer really
would be a lot simpler for config generation, automation, monitoring
etc (also when we want PWE3/AToM) between two CPEs at different
sites).

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
On (2014-08-26 09:56 +0100), James Bensley wrote:

Hi,

> I know this has been discussed before (more on the NANOG list) but
> what are people doing regarding MPLS down to the CPE?

I think most are not doing it.

> (i) My first idea was uRPF, on the 12000 routers it seems that uRFP
> can inspect MPLS;

Pretty sure this is not the case.

> (iii) Additional options...

RFC4364 page 32 last sentence specifically mandates that OptB implementation
only accepts label it has advertised out. But as far as I know only very
recent IOS-XR versions actually comply to the RFC here.
I think CsC implementations do label checking, but not 100% sure about it
either.

Personally I think we're missing MPLS option best fit here. Since OptB implies
you cannot have ACL, QoS or counters per connection. I'd like OptB where you
could opportunistically create new subinterface, when needed, something like
this http://p.ip.fi/BQsj.txt

> I'm all ears! Is anyone running MPLS to the customer rather than
> multiple option A perings to each CPE? When we do large roll outs of
> 1000 CPEs with each CPE having a minimum of 3 and maximum of ~10 VRFs
> we end up having thousands of peerings. MPLS to the customer really
> would be a lot simpler for config generation, automation, monitoring
> etc (also when we want PWE3/AToM) between two CPEs at different
> sites).

VRF Lite is how people who care about security do it today :/

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
James,
ASR9K has mpls urpf support. We are planning to support the same on ASR920 and ASR903 RSP2.
http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-3/mpls/configuration/guide/b_mpls_cg43xasr9k/b_mpls_cg43asr9k_chapter_011.html#task_19C44FE6D33F4F8BADAF64614C1DB339

MPLS uRPF and proper control plane authentication should be able to address your concerns. I think Autonomic Networking will also help since it builds secure channel infrastructure.

Best Regards,

[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]

Waris Sagheer
Technical Marketing Manager
Service Provider Access Group (SPAG)
waris@cisco.com<mailto:waris@cisco.com>
Phone: +1 408 853 6682
Mobile: +1 408 835 1389

CCIE - 19901


<http://www.cisco.com/>



This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html



From: James Bensley <jwbensley@gmail.com<mailto:jwbensley@gmail.com>>
Date: Tuesday, August 26, 2014 at 1:56 AM
To: "cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>" <cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>>
Subject: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs

Hi All,

I know this has been discussed before (more on the NANOG list) but
what are people doing regarding MPLS down to the CPE?

Even though we own our CPEs and customers typically don't have access
to them (or perhaps restricted show commands) it is a security concern
that customers can send labelled packets back into the network if we
enable MPLS on the CE facing interface on our PE. There is also the
concern of route injection but I believe that risk can be removed by
enabling MD5 on BGP and LDP sessions between CE and PE.

(i) My first idea was uRPF, on the 12000 routers it seems that uRFP
can inspect MPLS;

From : http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/srpf_gsr.html
"All Layer 2 encapsulation and transport types are supported,
including ATM AAL5, ATM cell relay, Ethernet (VLAN and port modes),
Frame Relay, HDLC, and PPP over MPLS; for more information, refer to
Any Transport over MPLS."
...
"Although the Unicast RPF in Strict Mode feature filters only IPv4
packets in IP or MPLS traffic, you can configure IOS software features
that manage other traffic on the same interface, such as IP
forwarding, MPLS features, Frame Relay switching, ATM switching, and
Any Transport over ATM (AToM) connections. However, Unicast RPF
filtering is only applied to incoming traffic on IP routing interfaces
and not on packets processed by Frame Relay or ATM switching or
transmitted over AToM pseudowire commendations."

We aren't using 12000 though; At the access layer we're using
ME3600/ME3800/6500/7600/ASR1K and we're looking at 6880-X to remove
the smaller access layer 6504/6505/7604/7607 type chassis. I can't
find any indication that any of those can support MPLS in uRPF so I
think that idea is useless unless someone else can show me some
contradictory information?

(ii) My second idea was label value range restrictions

Since the average CPE may have 3-5 VRFs on it with say 10 routes in
each we could perhaps fiddle with the label allocation rules by
setting 1000-1999 to be the usable range at PoP A, and 2000-2999 at
PoP B and so on. We can restrict the routes that enter the LFIB at the
PEs and which ones get labels allocated to them. Techniques like this
reduce the surface area of potential attack and make it difficult to
send in packets with a valid label (or label stack) but they seem more
like security through obscurity to me.

(iii) Additional options...

I'm all ears! Is anyone running MPLS to the customer rather than
multiple option A perings to each CPE? When we do large roll outs of
1000 CPEs with each CPE having a minimum of 3 and maximum of ~10 VRFs
we end up having thousands of peerings. MPLS to the customer really
would be a lot simpler for config generation, automation, monitoring
etc (also when we want PWE3/AToM) between two CPEs at different
sites).

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
Hi All,

Thanks for your input so far.

Waris do you know if IOS will support the full RFC 4364 requirement
any time soon or can it be a feature request: "An ASBR should never
accept a labeled packet from an EBGP peer unless it has actually
distributed the top label to that peer." - I would like to see uRPF
MPLS in the ME3x00 boxes.

As for the ASR920, how soon do you think this feature will be in
there, I'd be interesting in arrange a loan-for-test.

Interesting to know its already in the ASR9K but to expensive for
access layer stuff :)

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
On 26 August 2014 10:26, Saku Ytti <saku@ytti.fi> wrote:
> Personally I think we're missing MPLS option best fit here. Since OptB implies
> you cannot have ACL, QoS or counters per connection. I'd like OptB where you
> could opportunistically create new subinterface, when needed, something like
> this http://p.ip.fi/BQsj.txt

Dare I say it what access/agg layer boxes (such as ME3x00) from Cisco
will perform QoS deeper than one MPLS label?

Is there no product that will look more than one label deep for QoS so
we can have option B peering to CPE with QoS? What I would be looking
for is a box that can look two labels deep for example so we can see
voice class packets irrelevant of the VPN they belong to? At the
inter-AS boundary between SPs that wouldn't be much help but at the
PE-CE AS border its a much smaller scale; we know the link speed, the
VPNs required at each end site, the services and their QoS
requirements etc.

Opt D (Cisco "Opt AB") could be a good tool if you don't need QoS and
ACLs on all VPNs, only creating the hybrid Opt A peerings, breaking
them out from the Opt B link for VPNs that do need QoS/ACL etc but
thats no good if all VPNs require QoS (multi-tenant building with
shared CPE, tenant in each VRF and each run's VOIP for example).

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
On (2014-08-28 15:05 +0100), James Bensley wrote:

Hi James,

> Dare I say it what access/agg layer boxes (such as ME3x00) from Cisco
> will perform QoS deeper than one MPLS label?

ASR9001 certainly. I'm not sure what ME3x00 could in theory do, it does not
seem hard for me to think it could classify based on IP packets for MPLS
encapped packets.
In any case, label stack would be 1.

> Is there no product that will look more than one label deep for QoS so
> we can have option B peering to CPE with QoS? What I would be looking
> for is a box that can look two labels deep for example so we can see
> voice class packets irrelevant of the VPN they belong to? At the

If you're thinking of optionB, label stack would be between ASBRs 1 label
deep.

> Opt D (Cisco "Opt AB") could be a good tool if you don't need QoS and
> ACLs on all VPNs, only creating the hybrid Opt A peerings, breaking
> them out from the Opt B link for VPNs that do need QoS/ACL etc but
> thats no good if all VPNs require QoS (multi-tenant building with
> shared CPE, tenant in each VRF and each run's VOIP for example).

AB is interesting, I wonder if anyone else implements it, and I guess security
is same as B, non-existing. Data-plane is labeled, so you would still need
label security.

Now if it would be A + single-bgp with new magic NLRI giving multiplexing
discriminator (VLAN, DLCI, PVC), that might be interesting :).
It would work without any HW requirement and it would be secure by-default, as
any spooffed multiplexing discriminator would simply hit unconfigured logical
interface (provided NNI is connected to router port, not switch port)
This might be interesting for many existing NNIs, because BGP per VLAN scales
really poorly, measlybox could roll 1000 VLAN NNI without any trouble at
all, but running 1000 BGP sesssions is non-starter for many boxes.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
On 28 August 2014 20:35, Saku Ytti <saku@ytti.fi> wrote:
>> Dare I say it what access/agg layer boxes (such as ME3x00) from Cisco
>> will perform QoS deeper than one MPLS label?
>
> ASR9001 certainly. I'm not sure what ME3x00 could in theory do, it does not
> seem hard for me to think it could classify based on IP packets for MPLS
> encapped packets.
> In any case, label stack would be 1.
>
...
>
> If you're thinking of optionB, label stack would be between ASBRs 1 label
> deep.

Yeah I new the ASR9K could fo it but nothing smaller I know of. Yes
our ME3x00's are happy to QoS to one label although I was thinking of
MPLS down to CPE with AToM L2VPNs so a 2nd label is required; perhaps
a method of copying the EXP from the bottom label to the top label so
it can become subject to QoS would be useful.

>> Opt D (Cisco "Opt AB") could be a good tool if you don't need QoS and
>> ACLs on all VPNs, only creating the hybrid Opt A peerings, breaking
>> them out from the Opt B link for VPNs that do need QoS/ACL etc but
>> thats no good if all VPNs require QoS (multi-tenant building with
>> shared CPE, tenant in each VRF and each run's VOIP for example).
>
> AB is interesting, I wonder if anyone else implements it, and I guess security
> is same as B, non-existing. Data-plane is labeled, so you would still need
> label security.

Yeah so we're back to square one. Without uRPF support for MPLS in
boxes smaller than ASR9K this is a major feature that Cisco are
missing in my opinion. By the time my current project completes will
will probably hit 10k BGP sessions to CPEs that could probably be
circa 3k~ if we had secure MPLS to the CPE.

I've had an off-list recommendation for CsC but getting down to the
nuts and bolts of it I would simply end up with another label on the
stack making customer traffic 3 labels passing through the core
instead of 2. Unless they meant something else I didn't realise? CsC
will just obscuring the security issue, making it harder to use a
customer tail circuit to originate IP packets to something outside of
their VPNs into our CsC core, but it doesn't stopping it.

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
> Yeah I new the ASR9K could fo it but nothing smaller I know of. Yes our
> ME3x00's are happy to QoS to one label although I was thinking of MPLS
> down to CPE with AToM L2VPNs so a 2nd label is required; perhaps a method
> of copying the EXP from the bottom label to the top label so it can become
> subject to QoS would be useful.

Well you could do L2TPv3 for L2 services between CEs.
During the imposition all labels in the label stack gain the same label.

adam

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
Two labels QOS will work fine since bottom label EXP is copied to the top label so there should not be any issues with the QOS in this case if you are using ME family.
I have put uRPF in the roadmap on ASR920 but I need customer names since it is required for feature request. I would appreciate if you can unicast me the customer names who would be interested in this feature.
I still do not understand why do we need large number of BGP sessions on a single small PE router like ME3600X? Why cannot use Tunk interface where vlan can be differentiator and limit the sessions to 200- 300?

Best Regards,

[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]

Waris Sagheer
Technical Marketing Manager
Service Provider Access Group (SPAG)
waris@cisco.com<mailto:waris@cisco.com>
Phone: +1 408 853 6682
Mobile: +1 408 835 1389

CCIE - 19901


<http://www.cisco.com/>



This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html



From: James Bensley <jwbensley@gmail.com<mailto:jwbensley@gmail.com>>
Date: Friday, August 29, 2014 at 1:03 AM
To: "cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>" <cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>>
Subject: Re: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs

On 28 August 2014 20:35, Saku Ytti <saku@ytti.fi<mailto:saku@ytti.fi>> wrote:
Dare I say it what access/agg layer boxes (such as ME3x00) from Cisco
will perform QoS deeper than one MPLS label?

ASR9001 certainly. I'm not sure what ME3x00 could in theory do, it does not
seem hard for me to think it could classify based on IP packets for MPLS
encapped packets.
In any case, label stack would be 1.

...

If you're thinking of optionB, label stack would be between ASBRs 1 label
deep.

Yeah I new the ASR9K could fo it but nothing smaller I know of. Yes
our ME3x00's are happy to QoS to one label although I was thinking of
MPLS down to CPE with AToM L2VPNs so a 2nd label is required; perhaps
a method of copying the EXP from the bottom label to the top label so
it can become subject to QoS would be useful.

Opt D (Cisco "Opt AB") could be a good tool if you don't need QoS and
ACLs on all VPNs, only creating the hybrid Opt A peerings, breaking
them out from the Opt B link for VPNs that do need QoS/ACL etc but
thats no good if all VPNs require QoS (multi-tenant building with
shared CPE, tenant in each VRF and each run's VOIP for example).

AB is interesting, I wonder if anyone else implements it, and I guess security
is same as B, non-existing. Data-plane is labeled, so you would still need
label security.

Yeah so we're back to square one. Without uRPF support for MPLS in
boxes smaller than ASR9K this is a major feature that Cisco are
missing in my opinion. By the time my current project completes will
will probably hit 10k BGP sessions to CPEs that could probably be
circa 3k~ if we had secure MPLS to the CPE.

I've had an off-list recommendation for CsC but getting down to the
nuts and bolts of it I would simply end up with another label on the
stack making customer traffic 3 labels passing through the core
instead of 2. Unless they meant something else I didn't realise? CsC
will just obscuring the security issue, making it harder to use a
customer tail circuit to originate IP packets to something outside of
their VPNs into our CsC core, but it doesn't stopping it.

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
Hi James,

I would recommend Option C + RFC3107.
That is couple of MP-eBGP sessions from CE to local RRs and RFC3107 to carry loopbacks and their particular labels between PEs and CEs (No LDP).
BGP sessions will be protected so that customer can not inject false prefixes or labels should the CE be replaced by a rouge device.


adam
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of
> James Bensley
> Sent: Tuesday, August 26, 2014 10:56 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs
>
> Hi All,
>
> I know this has been discussed before (more on the NANOG list) but what
> are people doing regarding MPLS down to the CPE?
>
> Even though we own our CPEs and customers typically don't have access to
> them (or perhaps restricted show commands) it is a security concern that
> customers can send labelled packets back into the network if we enable
> MPLS on the CE facing interface on our PE. There is also the concern of route
> injection but I believe that risk can be removed by enabling MD5 on BGP and
> LDP sessions between CE and PE.
>
> (i) My first idea was uRPF, on the 12000 routers it seems that uRFP can
> inspect MPLS;
>
> From :
> http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/srpf_gsr.h
> tml
> "All Layer 2 encapsulation and transport types are supported, including ATM
> AAL5, ATM cell relay, Ethernet (VLAN and port modes), Frame Relay, HDLC,
> and PPP over MPLS; for more information, refer to Any Transport over
> MPLS."
> ...
> "Although the Unicast RPF in Strict Mode feature filters only IPv4 packets in
> IP or MPLS traffic, you can configure IOS software features that manage
> other traffic on the same interface, such as IP forwarding, MPLS features,
> Frame Relay switching, ATM switching, and Any Transport over ATM (AToM)
> connections. However, Unicast RPF filtering is only applied to incoming traffic
> on IP routing interfaces and not on packets processed by Frame Relay or
> ATM switching or transmitted over AToM pseudowire commendations."
>
> We aren't using 12000 though; At the access layer we're using
> ME3600/ME3800/6500/7600/ASR1K and we're looking at 6880-X to remove
> the smaller access layer 6504/6505/7604/7607 type chassis. I can't find any
> indication that any of those can support MPLS in uRPF so I think that idea is
> useless unless someone else can show me some contradictory information?
>
> (ii) My second idea was label value range restrictions
>
> Since the average CPE may have 3-5 VRFs on it with say 10 routes in each we
> could perhaps fiddle with the label allocation rules by setting 1000-1999 to be
> the usable range at PoP A, and 2000-2999 at PoP B and so on. We can restrict
> the routes that enter the LFIB at the PEs and which ones get labels allocated
> to them. Techniques like this reduce the surface area of potential attack and
> make it difficult to send in packets with a valid label (or label stack) but they
> seem more like security through obscurity to me.
>
> (iii) Additional options...
>
> I'm all ears! Is anyone running MPLS to the customer rather than multiple
> option A perings to each CPE? When we do large roll outs of
> 1000 CPEs with each CPE having a minimum of 3 and maximum of ~10 VRFs
> we end up having thousands of peerings. MPLS to the customer really would
> be a lot simpler for config generation, automation, monitoring etc (also when
> we want PWE3/AToM) between two CPEs at different sites).
>
> Cheers,
> James.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
On Aug 30, 2014, at 4:54 AM, Waris Sagheer (waris) <waris@cisco.com> wrote:

> Why cannot use Tunk interface where vlan can be differentiator and limit the sessions to 200- 300?

This is something I was wondering, as well . . .

----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Equo ne credite, Teucri.

-- Laocoön


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
On (2014-08-29 22:43 +0000), Vitkovský Adam wrote:

Hi Adamn,

> I would recommend Option C + RFC3107.
> That is couple of MP-eBGP sessions from CE to local RRs and RFC3107 to carry loopbacks and their particular labels between PEs and CEs (No LDP).
> BGP sessions will be protected so that customer can not inject false prefixes or labels should the CE be replaced by a rouge device.

Customer can inject labels to wire to reach arbitrary customer. As labels are
not allocated random, it's quite easy, then you can inject traffic to
customer, but not receive anything from customer. But some other attack vector
could be used to compromise that direction, such as if provider offers bgp
flowspec and is not careful, you could use flowspec to ask diversion of
packets to your VRF (And bridge them back via your OptC hack for transparent
sniffing)

How likely this is, is of course very debatable. But if your main product is
L3 MPLS VPN, might be good idea to keep exposure to minimum.
OptB with label checking reduces risk to 'shared' customer, so customer can
hop between /their/ vrfs, but that is fine, because they can do it anyhow by
moving LAN ports.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
Hi Saku,

I see, as the Cisco mpls label sec checks only the top-most label we have to make sure the topmost label is indeed the VPN label which applies only to opt.B with direct link peering and explicit null sig. scenario and possibly it could work in Option C where the PE (acting as ASBR&Inter-AS-RR) BGP-peers with CE via a direct link so that there is just the VPN label in the label stack.
Or am I getting it wrong?

adam
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of
> Saku Ytti
> Sent: Saturday, August 30, 2014 11:09 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs
>
> On (2014-08-29 22:43 +0000), Vitkovský Adam wrote:
>
> Hi Adamn,
>
> > I would recommend Option C + RFC3107.
> > That is couple of MP-eBGP sessions from CE to local RRs and RFC3107 to
> carry loopbacks and their particular labels between PEs and CEs (No LDP).
> > BGP sessions will be protected so that customer can not inject false
> prefixes or labels should the CE be replaced by a rouge device.
>
> Customer can inject labels to wire to reach arbitrary customer. As labels are
> not allocated random, it's quite easy, then you can inject traffic to customer,
> but not receive anything from customer. But some other attack vector could
> be used to compromise that direction, such as if provider offers bgp flowspec
> and is not careful, you could use flowspec to ask diversion of packets to your
> VRF (And bridge them back via your OptC hack for transparent
> sniffing)
>
> How likely this is, is of course very debatable. But if your main product is
> L3 MPLS VPN, might be good idea to keep exposure to minimum.
> OptB with label checking reduces risk to 'shared' customer, so customer can
> hop between /their/ vrfs, but that is fine, because they can do it anyhow by
> moving LAN ports.
>
> --
> ++ytti
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
On (2014-09-02 07:54 +0000), Vitkovský Adam wrote:

Hi Adam,

> I see, as the Cisco mpls label sec checks only the top-most label we have to make sure the topmost label is indeed the VPN label which applies only to opt.B with direct link peering and explicit null sig. scenario and possibly it could work in Option C where the PE (acting as ASBR&Inter-AS-RR) BGP-peers with CE via a direct link so that there is just the VPN label in the label stack.

If I understood that correctly, you propose in OptC we verify the top label,
we distributed it, so we should be able to verify it is one of ours. However,
I don't think this brings us any security? Because the 2nd label, may be
another PE box, so attack is just going to have to take round-trip via one of
the allowed egress PE boxes, before going to the target PE?

For OptB, I think verification should be stack is 1 label deep, and we've just
ourselves advertised the label, so there should be no room for spoofing.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
Hi Saku,

> Saku Ytti
> Sent: Tuesday, September 02, 2014 4:09 PM
> If I understood that correctly, you propose in OptC we verify the top label,
> we distributed it, so we should be able to verify it is one of ours. However, I
> don't think this brings us any security? Because the 2nd label, may be
> another PE box, so attack is just going to have to take round-trip via one of
> the allowed egress PE boxes, before going to the target PE?
>
> For OptB, I think verification should be stack is 1 label deep, and we've just
> ourselves advertised the label, so there should be no room for spoofing.
>
I see now.
You are right this only works if the single label in the stack is the VPN label allocated by us.
And the only profile that matches this is OptB.

It would be great though if the local PE or ASBR could receive the VPN label that was advertised to the foreign CEs or PEs so that it could use it during the label-stack check. This way the PE or ASBR would be able to verify stack that is two labels deep.

Some knob or AF in BGP that would tell the ASBR, hey we know you don't have any VPNs configured but just keep the VPN labels (for all the Inter-AS prefixes) so that you can reference to them while doing label stack verification.

This could also work for L2VPNs where BGP is used to advertise L2VPN label (EVPN) or PW label (standard L2VPN).

adam


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
On (2014-09-04 08:26 +0000), Vitkovský Adam wrote:

Hi Adam,

> It would be great though if the local PE or ASBR could receive the VPN label that was advertised to the foreign CEs or PEs so that it could use it during the label-stack check. This way the PE or ASBR would be able to verify stack that is two labels deep.
>
> Some knob or AF in BGP that would tell the ASBR, hey we know you don't have any VPNs configured but just keep the VPN labels (for all the Inter-AS prefixes) so that you can reference to them while doing label stack verification.
>
> This could also work for L2VPNs where BGP is used to advertise L2VPN label (EVPN) or PW label (standard L2VPN).

Ack seems it could work for L3 MPLS VPN and Kompella pseudowires, you'd just
need to keep copy of everything from everyone's point of view. Didn't think
about it, but probably any interASN MPLS FRR would not work.

For me personally, in NNI, having multiple VLANs is not a problem, I get own
counters, QoS, ACL etc. Having BGP for each VLAN is a problem, as I may want
to support 1000 VLANs, which is easy, but 1000 BGP is hard.
If BGP could send VLAN in NLRI, then we'd only need 1 BGP session, and there
would be no security issue in VLAN forging, as that would simply hit
unconfigured logical interface.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
Hi Waris,

I have sent you an off list response. On-list thought, I agree lots of BGP
sessions to ME series is bad but there isn't much we can do facing the
customer because OptB isn't secure.

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs [ In reply to ]
On 4 September 2014 09:41, Saku Ytti <saku@ytti.fi> wrote:
> If BGP could send VLAN in NLRI, then we'd only need 1 BGP session

Indeed something like this would be great. Option D is the closest we can get;

I haven't tried in the lab yet but I wonder if it's possible using
Cisco Opt A+B down to a CPE (Opt D) to have one MP-BGP session for
control plane and many VLANs for each data plane path, if you then
break out all VPNs onto individual VLANs there will be no exchange of
MPLS tagged frames required, it may be possible to disable mpls
forwarding on the CE-facing interface.

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/