Hi Steve, Many thanks once again for the feedback and text suggestion!
(adding ipsec folks in CC) | I am happy if the tittle changes to "IKEv2-based Shared Secret Key for | O/TWAMP". Already changed in my local copy, and I will update the slides for this afternoon accordingly. | I suggest the following text: | In many cases, protecting unauthenticated O/TWAMP traffic using IPsec | security services is sufficient and provides the easiest solution to | secure sensitive traffic including O/TWAMP control and/or test traffic | and hide the O/TWAMP endpoint services from the external network with | IPsec tunnel mode for instance. This new mode is intended for the | following cases: | 1) when O/TWAMP traffic is bypassing IPsec protection and is running | over an external network exactly between two IKEv2 systems (maybe we | should elaborate on why this might be needed) | 2) when double protection is needed (should we drop this case and | recommend to avoid it?) How about the following, instead: We note that protecting unauthenticated O/TWAMP traffic using IPsec security services is sufficient in many cases. That said, protecting unauthenticated O/TWAMP control and/or test traffic via AH or ESP cannot provide various security modes and cannot authenticate part of a O/TWAMP packet as mentioned in <xref target="RFC4656"/>. In real-world deployments this may hinder timestamp accuracy. This document describes how to derive the shared secret key from the IKEv2 SA and employ the security service at the O/TWAMP layer. This method SHOULD be used when O/TWAMP traffic is bypassing IPsec protection and is running over an external network exactly between two IKEv2 systems. If this is ok, I can update the draft on the datatracker before lunch, and then we discuss the two points below during the meeting in the afternoon. | IMO this mode should use the same "rekeying behavior" as defined in | IKEv2 i.e. if a new IKE SA is established to carry the IKE traffic | before the keys expires and the old SA is then deleted, then I suggest | a new TWAMP test session is established and the old test session is | closed before the keys expires. We had a short chat with Emma and it seems that although the (O/TWAMP) shared secret key is derived from IKEv2 SA it is in fact a _separate key at the O/TWAMP layer_. That would mean that it's not necessary to update the shared secret key before it expires, even though a new IKEv2 SA is established. Doing so will disrupt the ongoing test session. So we do not see much benefit from a measurements pov. | I still think one mode is sufficient. I guess we still think that backwards compatibility is a good thing :) Best regards, Kostas | | Regards | Steve B | | -----Original Message----- | From: Kostas Pentikousis [mailto:k.pentikou...@eict.de] | Sent: July-14-14 1:18 PM | To: Steve Baillargeon; Brian Trammell; i...@ietf.org | Cc: draft-ietf-ippm-ip...@tools.ietf.org | Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03 | | 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
