Subject: Re: [secdir] SECDIR review of draft-ietf-softwire-encaps-ipsec-01

From: Lou Berger <[email-masked]>
Date: Fri, 30 Jan 2009 11:33:19 -0500

Steve,
         Thanks for the comments.  Please see below for in-line responses.

At 05:14 PM 1/29/2009, Stephen Kent wrote:
>Lou,
>
>As an IPsec guy with an interest in routing, I had a few questions 
>about this document.
>
>The current version of IPsec (See RFC 4301) suggests use of ESP-NULL 
>for the latter security services, rather that AH. However, this 
>document lists ESP and AH as the two IPsec encapsulation options. It 
>might be preferable to cite ESP-NULL in lieu of AH here, especially 
>if integrity is likely to be a commonly-selected service.

I believe Eric R (co-author) raised this exact point and proposed to 
exclude AH completely from the document.   I argued that AH wasn't 
deprecated by 4302 so we should allow for it, and also that this 
document wasn't the right place to provide guidance on use of AH vs. 
ESP-NULL.

>(It was not clear from the security consideration section whether 
>the primary focus of this tunnel option was to provide 
>confidentiality and integrity for traffic, or integrity.)

This option is provide a generic support mechanism that can be used 
for either and is intentionally not biased towards any IPsec tunneling type.

>I also think that the IPsec architecture document (RFC 4301) ought 
>to be cited here as normative, along with the IPsec protocol 
>specs.  If an RFC defines a means of triggering use of IPsec, and 
>defines parameters that indicate which  then the IPsec architecture 
>document and the relevant IPsec protocol documents strike me as 
>normative references. For example, when the encapsulation type calls 
>for an AH or ESP tunnel, the two routers in question need to have 
>SPD entries that specify the parameters for the tunnel that will be 
>created, e.g., indicating algorithms, modes, and optional services 
>like anti-replay. Just saying that a router will create an AH or ESP 
>tunnel is not specific enough to say what really will happen. The 
>SPD entries at each end will be used to fill in the details needed 
>to allow successful creation of the tunnel.  So, it seems 
>appropriate to note this in the document, and to cite the 
>architecture spec as normative.

100% agree.  This will be corrected in the next rev.

>Finally, there is no cite for IKE.  White it is true that IPsec does 
>not require use of IKE, I believe that the vast majority of IPsec 
>implementation use IKE. So, why not call for IKE use here as well, 
>to negotiate the SA parameters and manage keys. The IETF prefers 
>automated key management for security protocols, and IKE is the 
>designated key management protocol for IPsec. Since the document 
>cites the newest versions of AH and ESP, both of which assume use of 
>IKEv2, the right cite is to that version of IPsec.

okay, will add the reference.

Thanks,
Lou

>Thanks,
>Steve

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Lou Berger <[email-masked]>
Date: Fri, 30 Jan 2009 11:42:45 -0500

IKEv2 [RFC4306] will be in the next rev.

Thanks,
Lou

At 10:24 AM 1/30/2009, Stephen Kent wrote:
>Whoops, again. I missed that too. But, if one calls for use of the 
>latest AH and ESP specs, then IKEv2 is needed, since these versions 
>of the IPsec protocols rely on IKEv2 negotiation capabilities.
>
>Steve

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 9 Feb 2009 11:21:28 -0500 (Eastern Standard Time)

The word I used was "ironic", not "funny".

The irony is that there's a (relatively) weak mechanism being used to 
signal the use of a stronger mechanism.  Ten cent hasp for a $100 padlock, 
or something like that.

And that the signalling that IPsec is acceptable means that the signaller 
has the capability to be using IPsec, and so could use IPsec to protect 
the signalling channel (BGP) also.

--Sandy

On Mon, 9 Feb 2009, Eric Rosen wrote:

>
>> I found it somewhat ironic that signalling the use of public key
>> cryptography in these IPsec tunnels is itself to be protected by TCP MD5:
>
> Could you let me in on the joke?
>
>

---

From: Eric Rosen <[email-masked]>
Date: Mon, 09 Feb 2009 10:40:56 -0500