Subject: [ippm] Comments on draft-ietf-ippm-ipsec-01

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 6 Nov 2013 00:16:22 -0500

I have a few comments from a first-reading of the 
http://tools.ietf.org/html/draft-ietf-ippm-ipsec-01
they are listed by section, below.
regards,
Al

3.1. O/TWAMP-Control Security
...
   Three modes of operation are supported: unauthenticated,
   authenticated, and encrypted.
>>> Actually four in TWAMP, mixed mode is defined in http://tools.ietf.org/html/rfc5618

3.2. O/TWAMP-Test Security
   The O/TWAMP-Test protocol runs over UDP, using the sender and
   receiver IP and port numbers that were negotiated during the Request-
   Session exchange.  O/TWAMP-Test has the same three modes as with O/
   TWAMP-Control (unauthenticated, authenticated, and encrypted) and all
   O/TWAMP-Test sessions inherit the corresponding O/TWAMP-Control
   session mode.
>>> *WAMP-Test follows the Control mode, except in TWAMP mixed mode:
http://tools.ietf.org/html/rfc5618

3.4. O/TWAMP and IPsec
...
   When sender and receiver implement O/TWAMP over IPsec, they need to
   agree on a shared secret key during the IPsec tunnel establishment.
>>> Better to use the names of *WAMP entities rather than "sender and 
receiver". Control-Client, Server, etc.
   Subsequently, all IP packets sent by the sender are protected. 
>>> and not the "receiver" entity? This is a two way tunnel, right?
...
   Currently, after the test packets are received by the receiver, it
   cannot execute active measurement over IPsec.  That is because the
   receiver knows only the shared secret key but not the IPsec key,
   while the test packets are protected by the IPsec key ultimately.
>>> This explanation isn't clear, some entity at the receiver knows
the IPsec key, or the tunnel has been terminated before the stream
reaches the "receiver" (again we need some *WAMP entities). I seem to be
missing something.

   Therefore, it needs to be considered how to measure IP network
   performance in an IPsec tunnel with O/TWAMP.  Without this
   functionality, the use of OWAMP and TWAMP over IPsec is hindered.
>>> I'll keep reading, but I'm beginning to wonder if setting up an
IPsec tunnel and setting up *WAMP Control and Test protocols to transfer 
through the tunnel (unauthenticated so as not to waste processing on
redundant security) is the solution?  But what about the deployment of
IPsec in LTE networks: If a tunnel is established automatically for 
any data transfer, the *WAMP could be viewed as typical user traffic
inside an existing tunnel.

4.1. Shared Key Derivation
   If the AH protocol is used, the IP packets are transmitted in
   plaintext, but all O/TWAMP traffic is integrity-protected by IPsec.
   Therefore, even if the peers choose to opt for the unauthenticated
   mode, IPsec integrity protection is extended to O/TWAMP. 
>>> Is it quantifiably true that you can expect commodity networking 
devices to provide very high IPsec encap/decap performance, such that
http://tools.ietf.org/html/rfc5618 mixed mode is not needed with IPsec?

4.2. Server Greeting Message Update
   As discussed above, a binding association between the key generated
   from IPsec and the O/TWAMP shared secret key needs to be considered.
   The Security Association (SA) can be identified by the Security
   Parameter Index (SPI) and protocol uniquely for a given sender and
   receiver pair.  Therefore, these parameters should be agreed upon
   during the initiation stage of O/TWAMP-Control.  At the stage that
   the sender and receiver negotiate the integrity key, the IPsec
   protocol and SPI MUST be checked.  
>>> *WAMP entity names above.

                                   Only if the two parameters are
   matched with the IPsec information, MUST the O/TWAMP connection be
   established.
>>> The last sentence is rather awkward, suggest:
Establishment of the *WAMP Control session SHALL take place only when 
the two parameters are matched with the IPsec information.

>>> Note that a TCP connection needs to be established to send/receive 
the Server Greeting message.

   The Modes field in Figure 2 will need to allow for support of key
   derivation as discussed in Section 4.1.  As such, pending discussion
   in the IPPM WG, Modes value 8 MUST be supported by compatible
   implementations, indicating support for IPsec.
>>> We've already used quite a few mode values for TWAMP, including 8:
http://www.iana.org/assignments/twamp-parameters/twamp-parameters.xhtml

>>> it would probably be wise to stop here, and try to resolve the 
questions up to 4.2...

---

From: John Mattsson <[email-masked]>
Date: Wed, 6 Nov 2013 18:27:14 +0000

Good comments.

>>> I'll keep reading, but I'm beginning to wonder if setting up an
IPsec tunnel and setting up *WAMP Control and Test protocols to transfer through the tunnel (unauthenticated so as not to waste processing on redundant security) is the solution? 

I agree, and even if it's not chosen as the only solution, it should probably be the default.

>>> But what about the deployment of IPsec in LTE networks: If a tunnel is established automatically for any data transfer, the *WAMP could be viewed as typical user traffic inside an existing tunnel.

Yes.

/John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
Sent: den 6 november 2013 06:16
To: [email-masked]
Cc: [email-masked]
Subject: [ippm] Comments on draft-ietf-ippm-ipsec-01

3.4. O/TWAMP and IPsec
...
...
>>> This explanation isn't clear, some entity at the receiver knows
the IPsec key, or the tunnel has been terminated before the stream reaches the "receiver" (again we need some *WAMP entities). I seem to be missing something.

>>> I'll keep reading, but I'm beginning to wonder if setting up an
IPsec tunnel and setting up *WAMP Control and Test protocols to transfer through the tunnel (unauthenticated so as not to waste processing on redundant security) is the solution?  But what about the deployment of IPsec in LTE networks: If a tunnel is established automatically for any data transfer, the *WAMP could be viewed as typical user traffic inside an existing tunnel.

>>> The last sentence is rather awkward, suggest:
Establishment of the *WAMP Control session SHALL take place only when the two parameters are matched with the IPsec information.

>>> it would probably be wise to stop here, and try to resolve the 
questions up to 4.2...
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm