The MPLS WG Archive[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
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
|
|