Hi Kostas Some quick comments. The changes looks good but I think we need a couple of simple network diagrams to clarify the case when this mode is not needed and the case when it needed.
Here are two examples. 1) Case when new mode is not used/needed: Inner TWAMP Controller -- Internal Network ---IKE System 1 ---External Network ---IKE System 2 ---Internal Network ---Inner TWAMP Responder In this case #1, IPsec is protecting the TWAMP traffic (running in TWAMP unauthenticated mode for instance) and any other inner traffic over the external network but the TWAMP traffic is transmitted in cleartext and is not (fully) authenticated by the TWAMP endpoints Note 1: the controller and responder can also perform basic "ACL-like checking" based on the IP addresses and port numbers in TWAMP unauthenticated mode. Not sure what you mean by "In real-world deployments this may hinder timestamp accuracy". I don't see any problem with this case if the internal networks are considered "trustable" and both TWAMP endpoints are managed by the same "entity". Note 2: The Inner TWAMP responder and/or controller can be standalone or embedded within the IKE system. 2) Case when new mode is used/needed: IKE System 1 acting an Outer TWAMP Controller---External Network ---IKE System 2 acting as Outer TWAMP Responder In this case #1, IPsec is not protecting the TWAMP traffic. The TWAMP traffic is directly running over the external network in authenticated mode (etc...) in conjunction with the new mode. Note 3: The outer TWAMP responder and/or controller are embedded within each IKE system. Is this what you have in mind for the use case? Is there more to it? Regards Steve B -----Original Message----- From: Kostas Pentikousis [mailto:[email protected]] Sent: July-22-14 10:15 AM To: Steve Baillargeon Cc: [email protected]; Brian Trammell; [email protected]; [email protected] Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03 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:[email protected]] | Sent: July-14-14 1:18 PM | To: Steve Baillargeon; Brian Trammell; [email protected] | Cc: [email protected] | 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec
