The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Mar> msg00089



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Security issue re draft-ietf-mpls-in-ip-or-gre-07

  • From: Pekka Savola <pekkas@netcore.fi>
  • Date: Sat, 20 Mar 2004 10:29:31 +0200 (EET)
  • cc: erosen@cisco.com, <mpls@UU.NET>, <zinin@psg.com>, <bwijnen@lucent.com>

First -- there was a question asked on the feasibility of decapsulator 
checks vs operational checks.  I don't think that has been addressed.

Source address verification checks at the border is something that
every operator must do in any case.  Especially for their
infrastructure (network management, router loopbacks/ptp's, etc.)  
address blocks if nothing else.

Destination address verification checks (disallow anything coming to
your routers) at the border, however, is something that is not as
simple -- so I'd vager it may not be commonly done.  First, you have
to be very careful to include all the loopbacks and ptp addresses in
the list; unless the addressing plan has been made very carefully,
this is very challenging to keep in sync, and the list would be huge.
Further, you must be very careful to keep a list of exceptions as well
-- e.g., eBGP sessions, MSDP peerings, SSH access to your vendor for
bug chasing etc.; so my operational argument is that relying on this
being done is a long leap of faith, because it's rather complex to set
up and there are reasons why it is undesirable.

Further, if you want to get any internal protection, you have to
replicate these everywhere.  With source-based, you just run uRPF,
ACLs or the like and you're done.

On the other hand, source-based verification at the decapsulator,
coupled with the source verification at the border(s) eliminates these
threats to the degree that they can be eliminated (i.e., external
tunnels still can be spoofed if you know the right source address and
other networks allow such spoofing).

So, my arguments are basically:

 1) source-based edge verification is something what vendors have to
do *anyway*, and the IETF has been systematically recommending folks
to do so (BCP38, draft-savola-bcp38-multihoming-update-03; soon
RFC3708, etc.), and

 2) when in place, source-based decapsulator checks eliminate the
threats which can be eliminated.  You don't have to count on the
operator to perform any additional steps to get security against MPLS
injection.

On Fri, 19 Mar 2004, Bora Akyol wrote:
> 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. 

That doesn't help at all unless GRE decapsulator checks the source
address, and currently it does not -- as you can just use your valid
source address, and the GRE decapsulator allows it just fine.

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

Which is the scenario where you would use 1) GRE keying or 2) IPsec.  
Also, the attacker would also have to know/guess the IP source address
used by the tunnel from the outside, and the neighboring AS would have
to not filter spoofed packets.  If there are multiple ASs along the
path, this is indeed trickier -- but there is nothing to be done about
that except adding IPsec or the like.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings