[c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs

[Vitkovský Adam]

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 at puck.nether.net] On Behalf Of
> James Bensley
> Sent: Tuesday, August 26, 2014 10:56 AM
> To: cisco-nsp at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/