Subject: [ippm] WG: New Version Notification for draft-ietf-ippm-ipsec-03.txt

From: Kostas Pentikousis <[email-masked]>
Date: Thu, 5 Jun 2014 14:01:50 +0200

Dear all,

We have updated the draft on "Network Performance Measurement for IPsec" (see below). We would greatly appreciate comments from both IPPM and IPSEC as we're heading to finalizing this work item in IPPM.

Best regards,

Kostas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Donnerstag, 5. Juni 2014 13:56
An: Yang Cui; Emma Zhang; Emma Zhang; Yang Cui; Kostas Pentikousis; Kostas Pentikousis
Betreff: New Version Notification for draft-ietf-ippm-ipsec-03.txt

A new version of I-D, draft-ietf-ippm-ipsec-03.txt has been successfully submitted by Kostas Pentikousis and posted to the IETF repository.

Name:		draft-ietf-ippm-ipsec
Revision:	03
Title:		Network Performance Measurement for IPsec
Document date:	2014-06-05
Group:		ippm
Pages:		12
URL:            http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipsec-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/
Htmlized:       http://tools.ietf.org/html/draft-ietf-ippm-ipsec-03
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ipsec-03

Abstract:
   The O/TWAMP security mechanism requires that both the client and
   server endpoints possess a shared secret.  Since the currently-
   standardized O/TWAMP security mechanism only supports a pre-shared
   key mode, large scale deployment of O/TWAMP is hindered
   significantly.  At the same time, recent trends point to wider IKEv2
   deployment which, in turn, calls for mechanisms and methods that
   enable tunnel end-users, as well as operators, to measure one-way and
   two-way network performance in a standardized manner.  This document
   discusses the use of keys derived from an IKEv2 SA as the shared key
   in O/TWAMP.  If the shared key can be derived from the IKEv2 SA, O/
   TWAMP can support certificate-based key exchange, which would allow
   for more operational flexibility and efficiency.  The key derivation
   presented in this document can also facilitate automatic key
   management.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Brian Trammell <[email-masked]>
Date: Tue, 24 Jun 2014 17:09:39 +0200

Greetings, all,

This message begins WGLC on draft-ietf-ippm-ipsec-03. Please send any comments to the list (including simply "I've read the draft and support publication") by the end of day Tuesday 8 July 2014.

Thanks, cheers,

Brian

Begin forwarded message:

> From: Kostas Pentikousis <[email-masked]>
> Subject: [ippm] WG: New Version Notification for draft-ietf-ippm-ipsec-03.txt
> Date: 5 Jun 2014 14:01:50 GMT+2
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> Dear all,
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Steve Baillargeon <[email-masked]>
Date: Wed, 25 Jun 2014 16:56:32 +0000

Hi Kosta, Hi Brian
I support with the following comments:

- The tile of the draft is misleading. It should say something like O/TWAMP Shared Secret Key Feature
- 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 
- 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.
- 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.
- 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.

Regards
Steve Baillargeon
Ericsson

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: June-24-14 11:10 AM
To: [email-masked]
Subject: [ippm] WGLC on draft-ietf-ippm-ipsec-03

Greetings, all,

Thanks, cheers,

Brian