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

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

> -----Original Message-----
> From: Jiang Yuan-long [mailto:yljiang@huawei.com] 
> Sent: Wednesday, June 24, 2009 2:28 AM
> To: Anoop Ghanwani
> Cc: mpls@ietf.org
> Subject: Re: [mpls] validating incoming frames at an Ethernet 
> interface of an LSR
> 
> 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" <anoop@brocade.com>
> To: <mpls@ietf.org>
> Sent: Wednesday, June 24, 2009 8:49 AM
> Subject: [mpls] validating incoming frames at an Ethernet 
> interface of an 
> LSR
> 
> 
> >
> > 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
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls 
> 
> 