The MPLS WG Archive

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

And my point is that for a clueless attacker, src address
check may be useful (although I would think most
implementations of GRE would throw these junk packets away
since the MPLS label underneath should also match), 
for a more determined attacker,
src address check is not so useful (in fact one could say
useless).

I think a more acceptable way to protect one's network is to enable
uRPF (at least in some mode), AND also packet filtering
based on the destination address network of your
GRE tunnels at the edges of your network. With 
efficient use of subnets, for the GRE tunnel endpoint
addresses, this can be handled by a small number
of filter entries. Do not allow packets that terminate
at your network elements
from outside the network unless the peers or the traffic
type is well known.

Only after you have done all this, if as an option someone
wants to enable src address checking, great.

But if you have not done any of the above, and think
that src address checking is buying you security,
I think this is kind of like locking the door,
but leaving the front windows of the house open.

And since we already seem to have IPSEC and IKE and they
seem to interoperating fine between vendors even
at relatively high speeds, why not use IPSEC with IKE
and really ensure that:

a) traffic is authentic and secure
b) it is coming from the correct endpoint

If this is within a domain or two, key management can be handled
reasonably well.

To sum it up IMHO, the text of the draft in the security section is fine
although we may want to add a brief sentence on using uRPF. 
If a user is deliberately choosing to NOT utilize IPSEC, I think they
are making a concious decision to take a calculated risk. And in this
scenario the best defense is to enable uRPF AND destination based
filtering
at the network borders. 

Regards,

Bora

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi] 
> Sent: Saturday, March 20, 2004 12:43 PM
> To: Bora Akyol
> Cc: erosen@cisco.com; mpls@UU.NET; zinin@psg.com; bwijnen@lucent.com
> Subject: RE: Security issue re draft-ietf-mpls-in-ip-or-gre-07
> 
> 
> On Sat, 20 Mar 2004, Bora Akyol wrote:
> > I think we are in agreement here,the text as it stands is fine, the 
> > additional requirement for checking the source address 
> provides really 
> > no additional protection for even the most clueless attacker.
> 
> The quote you took was taken out of context, and my intent 
> was to convey exactly the opposite message -- not sure how it 
> got through.
> 
> I think your argument is, "let's not bother to specify decapsulation 
> checks, because we can just specify that operators must deploy 
> destination-based checks if they want to be safe".
> 
> My argument is, "source-based decapsulation checks are very 
> useful on their own, and sufficient in most cases, as all the 
> operators should have deployed source-address based checks at 
> their borders already (and deploying destination-based checks 
> is infeasible, and can't be assumed/ensured, so we'll end up 
> with a lot of vulnerable MPLS networks)".
> 
> > The text however should mention uRPF somewhere in the 
> security section 
> > with a reference to BCP-38. And if one is doing uRPF is it "loose" 
> > mode or "strict" mode. BCP-38 only describes the "strict" mode.
> 
> Loose mode is practically useless in this context.
> 
> See recently published RFC3704 (BCP84) for more.  It's much 
> better than BCP38 (even if may say so: I'm co-author).
> 
> > And as far as GRE keying, I doubt that you can use that to 
> assure the 
> > security of the packets especially in high speed implementations.
> 
> People just haven't implemented it.. so it likely doesn't 
> help you much *today* but if folks believe this is important 
> for them, and this would be the best way to tackle the 
> problem, it would get done, I'd wager.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>