Subject: [mpls] validating incoming frames at an Ethernet interface of an LSR

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 23 Jun 2009 17:49:44 -0700

Let's say I have 3 routers R1, R2 & R3 connected
by a layer 2 switch.

Let's say R1 advertises a label, say L1, for a
certain FEC to R2.  Let's assume R1 has a global
LIB (i.e. assigns different labels each time one
is requested).

Now, if R3 sends a frame with L1 addressed to
R1's MAC address, would R1 just pick the frame
up and forward it, or would it actually notice
the problem and drop the frame?

I know we're getting into implementation here,
but would appreciate if someone can point me to
an RFC/draft that discusses this issue.

Thanks,
Anoop

---

From: Mitchell Erblich <[email-masked]>
Date: Tue, 23 Jun 2009 22:48:25 -0700

Anoop Ghanwani,

	On the non-RFC front I would suggest

	"MPLS Technology and Applications"
	by Davie and Rekhter

	Mitchell Erblich
	===========

On Jun 23, 2009, at 5:49 PM, Anoop Ghanwani wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Jiang Yuan-long <[email-masked]>
Date: Wed, 24 Jun 2009 17:28:05 +0800

Hi Anoop:

This is mentioned in "draft-ietf-l3vpn-ipsec-2547-05", which said:
   A Service Provider (SP) can protect against spoofed MPLS packets by
   the simple expedient of not accepting MPLS packets from outside its
   own boundaries (or more generally by keeping track of which labels
   are validly received over which interfaces, and discarding packets
   which arrive with labels that are not valid for their incoming
   interfaces)...
But this draft was expired long ago. Hope it helps you.

Cheers

Jiang Yuanlong

----- Original Message ----- 
From: "Anoop Ghanwani" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 24, 2009 8:49 AM
Subject: [mpls] validating incoming frames at an Ethernet interface of an 
LSR

---

From: [email-masked]
Date: Wed, 24 Jun 2009 17:48:47 +0800 (SGT)

Read RFC 3031 MPLS Architecture

---

From: Mitchell Erblich <[email-masked]>
Date: Wed, 24 Jun 2009 03:30:04 -0700

Group,

	I didn't think he wanted Refs from expired drafts
	and L1 MIGHT not be an invalid label. (see below)

	But since we are in somewhat of an implementation
	aspect.

	Some systems / OSs support ipchains and/or
	their equivs and thus, it is conceivable some rule
	on an input of R1 could DENY or REJECT a packet
	on the input interface based on a created rule.

	However, I wasn't 100% sure whether the example was
	specifying a local label binding or remote label binding,
	because the latter might not necessarily be a problem.

	But their also is the LDP (Label Distribution Protocol)
	which MIGHT generate the needed NOTIFICATION
	message versus just dropping the packet as suggested
	in the poster's post and the draft.

	So. I wanted to start the poster with the foundation
	of MPLS without first generating 100 questions and
	then giving him a set of rules to determine my answer.

	Mitchell Erblich
	=================

	
On Jun 24, 2009, at 2:28 AM, Jiang Yuan-long wrote:

> ----- Original Message ----- From: "Anoop Ghanwani"  
> <[email-masked]>
> To: <[email-masked]>
> Subject: [mpls] validating incoming frames at an Ethernet interface  
> of an LSR
>
>
>>

---

From: Himanshu Shah <[email-masked]>
Date: Wed, 24 Jun 2009 05:38:02 -0700

I don't believe any of such checks are done or talked about AFAIK.
In your example, an MPLS label will have to be bounded to SMAC
in order to authenticate the sender in data plane.

There are a number of things one can do in control plane and
may be some checks in data plane as far as label + interface
binding but that won't work in your example. I remember Eric Gray
sending out an email in some thread contrasting per platform
label vs per interface label wrt label to i/f authentication.
So there is some protection.

/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Tuesday, June 23, 2009 8:50 PM
To: [email-masked]
Subject: [mpls] validating incoming frames at an Ethernet interface of an LSR

Thanks,
Anoop

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 24 Jun 2009 10:09:50 -0700

It's actually not just the interface; it's the 
adjacency that matters.  This means that the validation
for the label would have to be done on a {src mac, vlan}
basis.  This, of course, only works for the 
top label in the stack.

Validating packets for labels beyond the first
gets even more tricky because there is no information
in the packet that can help identify that the
frame was transmitted by a peer to which that
label was distributed.

Anyway, it doesn't sound like the specs require
any kind of validation.  I wanted to make sure
I wasn't missing something obvious.

Anoop

> From: Jiang Yuan-long [mailto:[email-masked]] 
> Sent: Wednesday, June 24, 2009 2:28 AM
> To: Anoop Ghanwani
> Cc: [email-masked]
> Subject: Re: [mpls] validating incoming frames at an Ethernet 
> interface of an LSR
> 
> Hi Anoop:
>

---

From: Jiang Yuan-long <[email-masked]>
Date: Thu, 25 Jun 2009 09:49:38 +0800

The default is no validation, but both IP/MPLS Forum19.0.0 and
draft-ietf-mpls-mpls-and-gmpls-security-framework-05 recommend
to verify that a label received accross an interconnect was actually 
assigned
 to a LSP accross that interconnet, otherwise the packet must be dropped.

With regard to your example,  i.e., validation of a label based on (smac, 
vlan),
is truly implementation specific, I'm not sure there is any specs with such 
a detail.

    Regards
Jiang Yuanlong

----- Original Message ----- 
From: "Anoop Ghanwani" <[email-masked]>
To: "Jiang Yuan-long" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 25, 2009 1:09 AM
Subject: RE: [mpls] validating incoming frames at an Ethernet interface of 
an LSR

Anoop

> =