Subject: [mpls] FW: ldp-hello-crypto-auth comments - Eric

From: Eric Gray <[email-masked]>
Date: Mon, 23 Jul 2012 13:10:21 -0400

Folks,

	I am providing a summary of an off-line discussion on one
of my comments.  I am doing this based on a request from Adrian
as routing Co-AD.

	The particular comment related to use of IPSec as one (of
possibly several) alternatives to the proposal in the draft.  I
made the comment because of a concern that a question along the
lines of what I was asking used to be one that we could expect
from the Security AD later on.

	It turns out that - as with many things - the Security
landscape has changed.  IPSec no longer appears to enjoy the
"favored son" status it once had.  As a result, I received a
very useful and informative reply that should be shared with 
the MPLS list.

	Specifically, quoting most of a reply from Manav Bhatia:

"There are issues with IPSec because of which there is work going on
 in moving protocols away from it. 

"OSPFv3 was originally designed to use only IPSec for authentication 
 (RFC 4552). Recently, OSPF WG published a new standard track doc that
 extends OSPFv3 so that it can authenticate its protocol packets by an
 inband mechanism without relying on IPSec (RFC 6506). I am one of the
 co-authors of that work.

"We've had lot of discussions on IPSecME WG on deprecating Authentication
 Header (AH) and there is quite a good consensus on making sure that no 
 new mechanism is introduced that uses AH as the primary mechanism for
 authentication unless it has a very very strong reason for only using AH 
 and not ESP. You can look at

 http://tools.ietf.org/id/draft-bhatia-moving-ah-to-historic-00.txt 

 to get an idea of what I am alluding to.

"ESP too has its own share of problems. Because ESP basically does
 encryption, there is no good way to look at the ESP packet and figure 
 out if the packet is encrypted or not. This means that when an ESP 
 packet appears on the wire, routers will have to pass it to the IPSec 
 engine/module before it can be prioritized and put into the right CPU 
 queues. Almost all implementations that use IPSec for control plane do 
 IPSec processing in SW (as you may not require an IPSec blade on core 
 routers). This breaks the CPU QoS design since packets cant be deep 
 inspected in HW and put in right queues. Of course, we could also use
 Wrapped ESP (RFC 5840) that I had co-authored to avoid the traffic 
 invisibility issue that I have described here. However, WESP's still a 
 relatively new protocol that hasn't been extensively deployed. And then 
 there are other issues with IPSec which hold good for WESP as well.

"KARP WG has been chartered to provide a new key management protocol 
 that works for all routing and signaling protocols. The entire KARP 
 work effort has been divided into two phases. The first phase would be 
 to modify the routing/signaling protocols to support modern cryptography 
 algorithms and key agility. The second phase would be to design and move 
 to an automated key management mechanism. Our ldp-hello draft is part of 
 the Phase 1 of KARP where we try to strengthen the LDP base security by 
 protecting LDP hello's against some very basic attacks. I am also the 
 co-author of KARP Design guide (RFC 6518) and I suggest that you go 
 through that to understand where this work fits into the entire scheme 
 of things."

--
Eric