Re: [ippm] WGLC on draft-ietf-ippm-ipsec-03

[Kostas Pentikousis <[e-mail]>]

Hi Steve, all,

| I support with the following comments:

Many thanks for the support, much appreciated. 


| - The tile of the draft is misleading. It should say something like
| O/TWAMP Shared Secret Key Feature

I think we discussed the title some time ago. Personally I would take a bit of an issue with changing the title so late in the process, but I have to agree that as the draft evolved since Orlando, the title didn't do so accordingly. We're open to suggestions, although I am not excited about the word "Feature" in an IETF RFC title :) Would something like "IKEv2-based Shared Secret Key for O/TWAMP", for example, be ok with you?


| - The use case in section 1 is not clear. It should indicate this mode
| is intended for protecting and exchanging OWAMP/TWAMP test protocol
| between two IKEv2 systems when OWAMP/TWAMP control/test traffic is not
| protected by IPSec

The document does focus on how to derive O/TWAMP Shared Secret Key from IKEv2 SA. As per earlier discussions in Berlin and Vancouver, I think we already agreed that this is orthogonal to whether the O/TWAMP control/test traffic is transferred inside the IPsec tunnel or not. The admin or operator policy could play a role, for example. Of course, one should avoid a so-to-speak "double security protection".


| - I personally think the most common case is to protect OWAMP/TWAMP
| control/test traffic with IPsec. It is important to highlight the
| benefits associated with this new mode versus the common
| unauthenticated O/TWAMP mode protected via AH or ESP.

I think we mostly agree on this. Would you be so kind to propose some text to add? I guess a few of sentences would suffice at this stage

 
| - in section 4.1 first sentence, the requirement level is ambiguous. I
| think it should say...the shared secret MUST be derived ...(as opposed
| to can). Same comment for the second paragraph, the word if should be
| replaced by when.

Sounds good; we will update the draft before the meeting. Thanks for this point.


| - end of section 4.1, the expected behavior when the IKEv2 SA is
| rekeyed is not clear. Same is true when the IKEv2 SA is deleted for
| whatever reasons. What should the O/TWAMP  part of the IKE system do
| when the IKE SA is rekeyed or deleted? Should it close its test
| sessions and setup new test sessions using the key associated with the
| newly established IKEv2 SA? Waiting for the lifetime to expire does not
| make sense. And if you do, what happens next?


I'm not sure about this, although we would be happy to integrate proposed text from your end. The shared secret key generated from the SA could continue to be used until the lifetime expiration. Do you see a need to rekey the shared secret key immediately after the IKEv2 SA is rekeyed?

| - section 4.2. Three (3) new TWAMP modes are not needed. One TWAMP mode
| called Shared Secret Key should be sufficient. This mode can then be
| used on conjunction with the authenticated, encrypted and mixed modes.
| Please do not use the X mode over IKEv2. The text "over" is always
| misleading.


I need to go back to my notes wrt the discussion we had earlier. If I recall correctly, extending the Modes values is advantageous if one considers backwards compatibility with existing O/TWAMP clients. The Set-Up-Response Message contains a mode value which indicates unauthenticated, authenticated or encrypted. In this case, the O/TWAMP server cannot obtain the information whether to derive shared secret key from an IKEv2 SA or not, if the modes value is not extended. The Set-Up-Response Message must signal this in conjunction with the mode. Since  there is no unused field in the Set-Up-Response Message, isn't it better to extend Modes?


Best regards,

Kostas and Emma