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

From: Kostas Pentikousis <[email-masked]>
Date: Mon, 14 Jul 2014 19:18:26 +0200

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

---

From: Steve Baillargeon <[email-masked]>
Date: Mon, 21 Jul 2014 17:30:18 +0000

Hi Kostas
I am happy if the tittle changes to "IKEv2-based Shared Secret Key for O/TWAMP".

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?)

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. 

I still think one mode is sufficient.

Regards
Steve B

-----Original Message-----
From: Kostas Pentikousis [mailto:[email-masked]] 
Sent: July-14-14 1:18 PM
To: Steve Baillargeon; Brian Trammell; [email-masked]
Cc: [email-masked]
Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03

Hi Steve, all,

| - 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?

| - 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.

Best regards,

Kostas and Emma

---

From: Kostas Pentikousis <[email-masked]>
Date: Tue, 22 Jul 2014 16:14:53 +0200

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-masked]]
| Sent: July-14-14 1:18 PM
| To: Steve Baillargeon; Brian Trammell; [email-masked]
| Cc: [email-masked]
| 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

---

From: Steve Baillargeon <[email-masked]>
Date: Tue, 22 Jul 2014 14:42:08 +0000

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-masked]] 
Sent: July-22-14 10:15 AM
To: Steve Baillargeon
Cc: [email-masked]; Brian Trammell; [email-masked]; [email-masked]
Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03

Hi Steve,

Best regards,

Kostas
| 
| Regards
| Steve B
| 
| -----Original Message-----
| From: Kostas Pentikousis [mailto:[email-masked]]
| Sent: July-14-14 1:18 PM
| To: Steve Baillargeon; Brian Trammell; [email-masked]
| Cc: [email-masked]
| 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

---

From: Kostas Pentikousis <[email-masked]>
Date: Tue, 22 Jul 2014 16:54:05 +0200

Hi Steve,

| 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.

Simple network examples may be a good idea to orient the uninitiated reader. But adding network diagrams to scope the applicability is not an equally good idea. 

<snip>

| internal networks are considered "trustable" and both TWAMP endpoints

I'm not sure whether anyone really thinks that an "internal" network in the age of virtualization can be "trustable" :)

Best regards,

Kostas

---

From: Steve Baillargeon <[email-masked]>
Date: Tue, 22 Jul 2014 15:11:39 +0000

Hi Kostas
I must disagree here. 
Stating that unauthenticated mode is no longer applicable is incorrect.
I believe that adding network diagrams to scope the applicability is a good idea as long as the associated text is concise.
I am still confused about the new mode applicability :)

-Steve

-----Original Message-----
From: Kostas Pentikousis [mailto:[email-masked]] 
Sent: July-22-14 10:54 AM
To: Steve Baillargeon
Cc: [email-masked]; Brian Trammell; [email-masked]; [email-masked]
Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03

Hi Steve,

<snip>

Best regards,

Kostas

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 24 Jul 2014 02:07:24 +0300

> (adding ipsec folks in CC)

I quickly read this document and I think it needs much broaders review
from the IPsec people. This document is using internal IKEv2 keying
material outside IKEv2 SA context, meaning it can cause problems with
the actual security of the IKEv2 SA.

It uses

Shared secret key = PRF( SKEYSEED, "IPPM" )

to generate the shared key to be used in the ippm. The SKEYSEED is
internal IKEv2 keying material, and should not be exposed outside
IKEv2. All IKEv2 keying material to protect the IKEv2 SA is also
derived from that value. The generation looks quite safe, so it most
likely do not directly cause IKEv2 SA to be broken, but also as
SKEYSEED is internal to the IKEv2, it might not be available at all
outside the IKEv2 library. For example my IKEv2 code will never store
the SKEYSEED, it is temporary calculated and then used to calculate
the derived SK_* keys, and then immediately zeroed out.

It would be much better to use the SK_d or KEYMAT which is derived
from the SK_d for that purposes, as that is what SK_d was meant to be
used, (i.e to derive keys for other uses than IKEv2 SA protection or
authentication).

Also the section 4.1 talks about the lifetime of the shared secret
key, but I have no idea what expire time it is refering to. If it
refers to the Shared secret key generated above, then where is its
expire time defined?  IKEv2 does not negotiate lifetimes, and IKEv2 SA
rekey is the closest thing we have about lifetime in the IKEv2, but
the text explictly says that "shared secret key generated" can
continue to be used...

Anyways I thing this document needs more reviews especially from the
IPsec community, as it is using IKEv2 as KMP for something else than
IPsec (which is not a wrong thing to do, but you need to know what you
are doing).
-- 
[email-masked]

---

From: Kostas Pentikousis <[email-masked]>
Date: Thu, 24 Jul 2014 14:06:54 +0200

Hi Tero, all,

Many thanks for chimming in, much appreciated!

<snip> 

| Anyways I thing this document needs more reviews especially from the
| IPsec community, as it is using IKEv2 as KMP for something else than
| IPsec (which is not a wrong thing to do, but you need to know what you
| are doing).

Indeed, and as you may recall I have asked ipsec in the the past for comments/review wrt this draft. I'm very happy to see the comments and I think all at ippm will be even happier to see more of it.

Best regards,

Kostas

---

From: Brian Trammell <[email-masked]>
Date: Thu, 24 Jul 2014 08:30:43 -0400

hi Kostas, Tero, all,

Many thanks for the review!

For the benefit of the ipsec working group, there are still a few discussions from the ippm side but we expect these to be resolved soon, after which we'd like to request publication. One or two more reviews from ipsec in the meantime would be extremely useful.

Thanks again, best regards,

Brian (as co-chair, ippm)