The MPLS WG Archive

["Bora Akyol" <bora@cisco.com>]

Hi Eric

If I understand this correctly, the security threat is
unauthorized packet injection into an MPLS stream.

I think the text as it stands in the draft is fine for
covering this case. 
One thing I would add is the possibility of using
uRPF as described in BCP38 (strict mode) and hope
that it catches the spoofed packets. 
And wording to suggest that between ASs it is highly recommended to use
IPSEC to secure these packets. Key distribution is left as an exercise
to the reader :-)

I think a check as described below is almost nearly useless in the case
of a determined attacker if the tunnels are between ASs.

Regards,

Bora

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
> Of Eric Rosen
> Sent: Tuesday, March 16, 2004 11:28 AM
> To: mpls@UU.NET
> Cc: zinin@psg.com; pekkas@netcore.fi; bwijnen@lucent.com
> Subject: Security issue re draft-ietf-mpls-in-ip-or-gre-07
> 
> 
> One last issue remains from the IESG review of this little document. 
> 
> The issue is whether, when  a node decapsulates an mpls-in-ip 
> or mpls-in-gre packet, there should  be a requirement that 
> the node  verify that the source address from the 
> encapsulation header is  a source address from which we are 
> expecting to receive these encapsulated packets.
> 
> I am reluctant to put in such a requirement, for the 
> following reasons: 
> 
> 1. If  appropriate source address filtering  is done at  the 
> border routers,
>    nothing is added by having the decapsulator do this check. 
> 
> 2. There may be performance  implications (with consequent 
> hardware require-
>    ments) in requiring this check.
> 
> 3. The encapsulation does not come  with any built-in 
> signaling; whether the
>    list  of valid  source address  can be  determined  
> dynamically therefore
>    depends  on the  application which  is  using the  
> encapsulation. If  the
>    application  does  not  supply  appropriate signaling,  
> then  the  source
>    addresses would have to be manually configured. 
> 
> The argument for putting in such  a requirement is that it 
> obviates the need to  do source  address filtering  at  the 
> border  routers and  it makes  the security built-in, rather  
> than making it dependent on  operator action. (At least,  if  
> one  can assume  that  the  operator  doesn't have  to  
> manually configure the addresses at all  the decapsulators.)  
> I think the points made above provide a stronger argument to  
> the contrary, but the AD has requested that this issue be 
> considered by the WG.
> 
> Comments? 
> 
>