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

[albert.john at zte.com.cn]

>> 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?

1 question, by what criteria should
the packet from R3 to R1 with label L1 be considered as a problem?

If reason is that R1 does not advertise
it to R3 and R3 forwards arbitrary packet labeled with L1 to R1, then the
problem should be generalized as 

How can LSR distinguish the right labeled
packet from the wrongly labeled packet?

But I have the question : Shall we tell
whether a labeled packet is crrectly label or not?

Or just accept any labeled packet and
forward it as defined?

I think the answer is open and depends
on network design goal.

In draft MPLS/GMPLS Security framework
 , it says

"   Equipment must be able
to verify that a label received across an 
   interconnect was actually
assigned to a LSP arriving across that 
   interconnect. If a label
not assigned to a LSP arrives at this 
   router from the correct
neighboring provider, the packet must be 
   dropped.  This verification
can be applied to the top label only. 
   The top label is the received
top label and every label that is 
   exposed by label popping
to be used for forwarding decisions.  
    
   Equipment must provide
the capability of dropping MPLS-labeled 
   packets if all labels in
the stack are not processed.  This lets 
   SPs guarantee that every
label that enters its domain from another 
   carrier was actually assigned
to that carrier.  
"
but how to verify is still open.

If we do need to make the difference,
I agree with Mitchell Erblich on
"
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.
"
Will need some rules to filter out so
called wrongly labeled packet and take actions.

Regards,
Albert

Mitchell Erblich <erblichs at earthlink.net>
发件人:  mpls-bounces at ietf.org

2009-06-24 18:30

收件人	Jiang Yuan-long <yljiang at huawei.com>
抄送	mpls at ietf.org
主题	Re: [mpls] validating incoming frames at an Ethernet interface of        an LSR

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:

> 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 at brocade.com>
> To: <mpls at 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 at ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.