Re: [ippm] draft-ietf-ippm-ipsec-01 review

[John Mattsson <[e-mail]>]

Hi Emma,

Thanks for your reply! I have comments on some your comments, I also have some suggested text to add to the draft:

(resending without the original message as my previous attempt hit the 50 kB limit)

/John



In general I think the abstract and Introduction could be clearer in what the problems and use cases are and what the document tries to achieve. E.g. do the document want to measure the performance of IPsec or use IPsec for protection, or both. What are the problems, if any, of just sending O/TWAMP over the existing IPsec tunnel?

Emma: The draft currently aims to capitalize on IPsec for deriving keys for O/TWAMP. We will further edit the introductory text to address this point.

John: Based on the comment by Alfred Morton, I think you should maybe reconsider that. If you only want to use *WAMP between the IPsec endpoints, I too see little benefit in deriving keys. If you want to use *WAMP outside of the IPsec tunnel, it makes sense to derive keys.



I suggest adding:

"If *WAMP is used for measurements between the IPsec endpoints, *WAMP can be viewed as typical user traffic inside the existing tunnel. As IPsec can be assumed to provide the protection needed for traffic between the IPsec endpoints, unauthenticated *WAMP can be used."


While extracting keying material from IPsec would be nice, to my knowledge there is no standardized (or de facto standard) API to extract SKEYSEED, SK_d, KEYMAT or even SPI from an IPsec implementation. This was even one of the reasons IPsec was not chosen as the default security protocol for O/TWAMP. You could of course do it with a new proprietary implementation, but that kind of beats some of the purpose from the Abstract "gaining popularity in several deployment scenarios".

Work on an IPsec API started a couple a years ago http://tools.ietf.org/html/draft-ietf-btns-ipsec-apireq-00
but died, and even that work did prohibit extraction of keying material and discouraged the extraction of SPI as the SPI might change.
Has the API proposals been discussed in the ipsecme working group?
Emma: We received this comment at the last meeting (I think it was Yoav who commented on that). We believe that this is in fact implementation-dependent. For example, for those with existing IPsec and O/TWAMP implementations this should not be a blocking point. If there was a “standard” API, this protocol could benefit. But what we’re interested primarily here is O/TWAMP deployment at large scale and for networks that have already deployed IPsec.
John: I do not really understand how an nonexistent API would not be a problem for "those with existing IPsec and O/TWAMP implementations" and "networks that have already deployed IPsec". I think the draft should at least make clear that there is currently no standardized IPsec APIs.

I suggest adding:
"There is currently no standardized IPsec API to retrieve keys, SPI, protocol, algorithms, or even find out if IPsec is used. As IPsec may be terminated in a separate node, such an API may not be possible to implement. If IPsec is terminated in the same node as *WAMP an implementation-dependent API may be provided."



I think the approach in Section 4 with extracting keying material would only work with a proprietary IPsec implementation and modifications (adding new fields) to O/TWAMP.



Have approaches that do not require extracting keying information been considered?

Emma: I think we could discuss this in Vancouver. In the meantime, do you have text to suggest?
John: I can provide some more detailed text after the meeting, but two approaches  could be:

-If the Child SA is encrypted. A *WAMP shared secret could simply be transferred in the KeyID field (similar to how *WAMP session keys are transferred):

KeyID: "Shared secret: RdJprY3Nvzb34gUtn96sZXM"

This would only require changes in the part of the *WAMP implementation (typically a separate function) that retrieves the key. As today the function would take KeyID as input

RetrieveSharedSecretBasedOnKeyID("Shared secret: RdJprY3Nvzb34gUtn96sZXM")

but instead of looking for a preconfigured shared secret, the function would see the unique string "Shared secret" and just return "RdJprY3Nvzb34gUtn96sZXM".

-If the Child SA is authenticated or encrypted (and it always is). A *WAMP shared secret could be generated with a Diffie-Hellman key exchange in the server greeting and Set-Up-Response messages.

Server greeting would include new field with g^x
Set-Up-Response would include new field with g^y
Both client and server can now calculate the shared secret as g^xy.

These approaches would require small changes to *WAMP but no changes to IPsec. As stated before, there is no API to find out if IPsec is used, so the client and server would need to get that information out-of-band.