Subject: Re: [ippm] Ben Campbell's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Fri, 05 Jun 2015 16:22:48 -0500

(Oops, I misfiled this. Sorry for the slow response.)

Your response addresses my DISCUSS and all my comments. I will clear.

Thanks!

Ben.

On 29 May 2015, at 8:35, Kostas Pentikousis wrote:

> Dear Ben, all,
>
> Many thanks for the detailed review.
>
>
> | 
> ----------------------------------------------------------------------
> | DISCUSS:
> | 
> ----------------------------------------------------------------------
> |
> | In the last paragraph, the text indicates that if the IKEv2 SA is 
> rekeyed or
> | deleted, O/TWAMP can continue to use the same shared secret. The 
> language
> | seems to make such a continuance optional. Does that cause an 
> interoperability
> | problem if the endpoints don't agree on the strategy?
> |
> | If so, this may need a 2119 MUST (or possibly SHOULD).
> |
>
> Done, the document now reads:
>
> If rekeying for the IKEv2 SA or deletion of the IKEv2 SA occurs, the
> corresponding shared secret key generated from the SA MUST continue
> to be used until the O/TWAMP session terminates.
>
> | 
> ----------------------------------------------------------------------
> | COMMENT:
> | 
> ----------------------------------------------------------------------
> |
> | Section 1, paragraph 4:
> |
> | This paragraph casts the decision whether to send O/TWAMP inside or 
> outside of
> | an IPSec tunnel as a question of how you want to secure the O/TWAMP 
> packets.
> | It seems to me that this is really more a matter of what you want to 
> measure,
> | given that the tunneled data and non-tunneled data may have 
> different
> | performance capabilities.
>
> Edited accordingly, and now the text reads:
>
> In general, O/TWAMP measurement packets can be transmitted inside the
> IPsec tunnel, as it occurs with typical user traffic, or transmitted
> outside the IPsec tunnel.  This may depend on the operator's policy
> and the performance evaluation goal, and is orthogonal to the
> mechanism described in this document.  When IPsec is deployed,
> <snip>
>
> |
> | Sentence starting with "In this case...": The antecedent of "this" 
> is unclear.
>
> Done.
>
> |
> | Section 1, 2nd to last paragraph:
> |
> | I assume the last sentence means that IKEv2 derived keys SHOULD be 
> used
> | instead of shared secrets when otherwise using IKEv2. That seems to 
> add a
> | normative requirement to OWAMP and TWAMP in general, in which case 
> this doc
> | should be listed as updating those.
>
> Agreed.
>
> <snip>
>
> |
> | Section 4.1:
> |
> | Please expand HMAC on first mention.
>
> Done.
>
> | Section 5.1:
> |
> | "SK_d MUST be computed as per [ref]" :That doesn't need 2119 
> language.
> |
> | "string "IPPM" comprises four ASCII characters ": This is oddly 
> constructed.
> | Is this intended to observe that IPPM has 4 letters?
> |
>
>
> Done.
>
>
> | Section 5.2, paragraph after Figure 2: "Clearly, an implementation 
> ....
> | MUST ..."
> |
> | It is not as clear to me. Why does the use of IKEv2 create a 
> stronger
> | requirement to support all 3 protection modes?
>
> Indeed. The sentence was removed.
>
>
> | Section 5.3:, first paragraph:
> |
> | "The Set-Up-Response Message should be updated": Do you mean to say 
> it _is_
> | updated?
> |
> | Paragraph after figure 3:
> |
> | s/ "can uniquely identify" / "uniquely identifies"
> |
> Done.
>
> | 5.4, last sentence:
> |
> | The sentence is confusing. Do you mean to say that O/TWAMP SHOULD be
> | configured to use the tunnel?
> |
>
> The was some discussion earlier in the WG and that's why sec. 5.4 was 
> added. We have now edited the last sentence to read:
>
> In order to ensure
> authenticity and security, O/TWAMP packets between two IKEv2 systems
> SHOULD be configured to use the corresponding IPsec tunnel running
> over an external network even when using the O/TWAMP unauthenticated
> mode.
>
>
> Best regards,
>
> Kostas