Subject: [ippm] TWAMP test timeout questions

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Tue, 1 Apr 2008 13:37:10 -0700

To the authors of TWAMP,

In the section on Reflector Behaviour it is mentioned that the reflector
needs to reject packets that are outside of the timeout range.    Is the
timeout only effective after the Stop sessions is received or is it that
even before the stop sessions the Reflector is to reject packets with
sender timestamp outside the timeout range?   The latter expects that
the one-way delay is known a-priori.

I interpret it as the former rather than the latter, that is, timeout is
ONLY effective after a stop sessions is received, which is as mentioned
in the section on starting Test Streams.

Another question we have is can we individually stop sessions?   It
seems that all sessions with a Request-Session-Ack have to be stopped.

Also we never got a response to the question as to what is actually
included in the Stop sessions packet?   It seems that session headers
are not to be included, however, the same section say Skip Range and
Number of Packets are to be set to 0!

Another un-answered question is whether HMAC covers 96 octets or 32
octets for encrypted mode reflected packets.

Further, another un-answered question is whether the auth mode
encryption should cover the Sender Sequence Number in the reply packet
since if that is not protected it can lead to tampered roundtrip
statistics.

Also, should start messages include SIDs?

Thanks,
-Murtaza
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Lars Eggert <[email-masked]>
Date: Tue, 1 Apr 2008 21:40:53 -0700

Hi,

I'm trying to to the AD review that normally happens after a WG  
requests publication early, such that it overlaps with WGLC. For this  
document, that hasn't happened, but at least I'm not very late,  
because it is still being discussed.

Summary: Not quite ready. My main concern is around the TWAMP light  
variant, and there are a number of small things where the document  
would be improved by a more careful description or some editorial  
changes.

Detailed comments:

INTRODUCTION, paragraph 10:
   Nit: s/Measurment/Measurement/ (everywhere in the footer)

INTRODUCTION, paragraph 11:
 >     The IP Performance Metrics (IPPM) working group's One-way Active
 >     Measurement Protocol [RFC4656] (OWAMP) provides a common protocol
 >     for measuring one-way metrics between network devices.

   Rephrase the first sentence to not talk about the IPPM WG - it's
   ephemeral and for the RFC it doesn't matter where OWAMP came from.
   (In other words, cut "IP Performance Metrics (IPPM) working  
group's".)

Section 1., paragraph 1:
 >     The IETF IP Performance Metrics (IPPM) working group has  
completed
 >     a draft standard for the round-trip delay [RFC2681] metric.  IPPM
 >     has also completed a protocol for the control and collection of
 >     one-way measurements, the One-way Active Measurement Protocol
 >     (OWAMP) [RFC4656].

   See above - rephrase to not talk about IPPM.

Section 1., paragraph 2:
 >     Two-way measurements are common in IP networks, primarily because
 >     time accuracy is less demanding for round-trip delay

   I don't quite understand what you mean by "time accuracy is less
   demanding".

Section 2., paragraph 0:
 >  2. Protocol Overview

   This section is almost word-by-word identical to a big chunk of
   section 1.2. Merge?

Section 3., paragraph 2:
 >     All OWAMP [RFC4656] Control messages except for the Fetch-Session
 >     command apply to TWAMP.

   Does "apply to" mean that TWAMP implementations MUST implement all
   these OWAMP control messages? If yes, say so with RFC2119 terms.

Section 3.5, paragraph 2:
 >     In order to distinguish the session as a two-way versus a one-way
 >     measurement session the first octet of the Request-Session  
command
 >     MUST be set to 5.  Value of 5 indicates that this is a
 >     Request-Session for a two-way metrics measurement session.

   That text is a bit misleading. An "OWAMP Request-Session" will always
   have 1 in that octet. What you're doing here is defining a
   "Request-TW-Session" command (this is how it's called in the IANA
   registry below) that looks and is mostly processed like an OWAMP
   message, but has a 5 in the first octet (because OWAMP uses first
   octet codes 2-4 for other commands.) You should make sure that you
   call the command "Request-TW-Session" everywhere in the document, to
   be consistent with the code allocated in the IANA registry.

Section 3.5, paragraph 3:
 >     In TWAMP, the first octet is referred to as the Command Number,  
and
 >     the Command Number is a recognized extension mechanism. Readers  
are
 >     encouraged to consult the TWAMP Command Number Registry to
 >     determine if there have been additional values assigned.

   I'd argue that because this document creates a registry that in
   addition to TWAMP also covers OWAMP, it should update RFC4656, if  
only
   to alert implementers of OWAMP that an IANA registry exists that
   matters for OWAMP but that RFC4656 doesn't descibe.

Section 3.5, paragraph 4:
 >     If a TWAMP server receives an unexpected command number, it  
SHOULD
 >     respond with the Accept field set to 3 (meaning "Some aspect of
 >     request is not supported") in the Server-Start message.

   s/SHOULD/MUST/ (or else explain in which cases the SHOULD may
   disregarded)

Section 3.5, paragraph 6:
 >     Both Conf-Sender field and Conf-Receiver field MUST be set to 0
 >     since the Session-Reflector will both receive and send packets,  
and
 >     the roles are established according to which host initiates the  
TCP
 >     connection for control.  The server MUST interpret any non-zero
 >     value as zero.

   If the field is not zero, something is clearly wrong with the peer -
   shouldn't the session be aborted?

Section 3.5, paragraph 10:
 >     They MAY be set to 0, in which case the IP addresses used for the
 >     Session-Sender to Session-Reflector Control Message exchange MUST
 >     be used in the test packets.

   This seems to be a difference to OWAMP. Any particular reason why?
   (For TWAMP Light?)

Section 3.5, paragraph 14:
 >     Point (DSCP) as defined in [RFC2474].  The same value of DCSP  
MUST

   Nit: s/DCSP/DSCP/

Section 3.9, paragraph 1:
 >     The purpose of TWAMP is measurement of two-way metrics.  Two-way
 >     measurements do not rely on packet level data collected by the
 >     Session-Reflector such as sequence number, timestamp, and TTL.   
As
 >     such the protocol does not require the retrieval of packet level
 >     data from the Server and the Fetch-Session command is not defined
 >     in TWAMP.

   Since Fetch-Session is defined in OWAMP and TWAMP is a variant of
   that, I'd be good to define what TWAMP should do if it somehow
   receives a Fetch-Session message. (Suggestion: stop fail.)

Section 4.2.1, paragraph 21:
 >     Implementation note: Naturally, the key schedule for each
 >     TWAMP-Test session MAY be set up only once per session, not once
 >     per packet.

   s/MAY/MUST/ (or lowercase, since it's about an implementation choice
   and not the specification)

Section 5.1, paragraph 3:
 >     The responder follows the Session-Reflctor behavior of TWAMP as

   Nit: s/Session-Reflctor/Session-Reflector/

Section 5.2, paragraph 0:
 >  5.2 TWAMP Light

   If I understand this correctly, TWAMP Light requires a different
   processing than Complete TWAMP. The "implementers guide" section is
   not the place to define specification variants, especially because
   it's not clear that Light and Complete imoplementations can
   interoperate without knowing which variant the other side is using.  
If
   the two variants are desired by the WG, they need to be described in
   the specification, and there needs to be a mechanism such that Light
   and Complete implementations can figure out what variant they're
   talking to at the other end.

Section 8.1, paragraph 1:
 >     IANA will create an TWAMP-Control Command registry.  TWAMP- 
Control
 >     commands are specified by the first octet in OWAMP-Control  
messages
 >     as shown in section 3.4 of [RFC4656], and modified by this
 >     document. Thus this registry may contain sixteen possible values.

   Elsewhere in this document, the term "command number" is used. Please
   use one term consistently throughout the document.

Section 8.4, paragraph 2:
 >     Value  Description             Semantics Definition
 >     0      Reserved
 >     1      Forbidden
 >     2      Start-Sessions          RFC4656, Section 3.7
 >     3      Stop-Sessions           RFC4656, Section 3.8
 >     4      Fetch-Session           RFC4656, Section 3.9
 >     5      Request-TW-Session      this document, Section 3.5
 >     6      Experimentation         undefined, see Section 8.3.

   This document doesn't specify how implementations shold react if
   Reserved or Forbidden values are received. (Is there a difference?)

Section 10.1, paragraph 1:
 >        [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
 >                   Zekauskas, M., "A One-way Active Measurement  
Protocol
 >                   (OWAMP)", draft-ietf-ippm-owdp-11.txt, October  
2004.

   s/draft-ietf-ippm-owdp-11.txt/RFC 4656/

Section 10.1, paragraph 5:
 >        [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing
 >                  an IANA Considerations Section in RFCs, RFC 2474,
 >                  October 1998.

   s/RFC 2474/RFC 2434/ (copy&paste error?)

---

From: "Jeff W. Boote" <[email-masked]>
Date: Wed, 2 Apr 2008 15:18:04 -0600

>   matters for OWAMP but that RFC4656 doesn't descibe.

The IANA registry should not be for OWAMP as well. There is no reason  
to tie these together unless TWAMP is done in a way that actually  
extends the OWAMP protocol. It is not defined that way. As it is, it  
just makes use of many of the same messages. (See the archives for  
previous discussions on this.)

It is possible that OWAMP will be extended in the future and may need  
a registry. But, since TWAMP does not extend the OWAMP protocol, these  
registries should be separate.

jeff
--
Jeff W. Boote
[email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Thu, 3 Apr 2008 07:22:49 +0300

Hi,

On 2008-4-3, at 0:18, ext Jeff W. Boote wrote:
> The IANA registry should not be for OWAMP as well. There is no  
> reason to tie these together unless TWAMP is done in a way that  
> actually extends the OWAMP protocol. It is not defined that way. As  
> it is, it just makes use of many of the same messages. (See the  
> archives for previous discussions on this.)

but the current draft does tie together OWAMP and TWAMP, because the  
registry definition in Section 8.4 lists RFC4656 as the defining  
document for codepoints 2-4, and then adds codepoints 5-6 as TWAMP  
ones. This means that a hypothetical OWAMP revision can, for example,  
never use codepoint 5 for a new OWAMP message. If OWAMP and TWAMP are  
supposed to remain completely separate, then they need two registries  
(which is what you say below).

I also note that the entire document is written in a way that  
basically says "TWAMP is like OWAMP except for these changes in  
processing/message formats". At least to me, that doesn't drive home  
the point that OWAMP and TWAMP are completely separate protocols.  
Writing the specification in this way may minimize editing overhead,  
but it does leave the reader (well, me at least) with the impression  
that OWAMP and TWAMP are tightly related.

> It is possible that OWAMP will be extended in the future and may  
> need a registry. But, since TWAMP does not extend the OWAMP  
> protocol, these registries should be separate.

Lars

---

From: "Jeff W. Boote" <[email-masked]>
Date: Thu, 3 Apr 2008 09:10:37 -0600

On Apr 2, 2008, at 10:22 PM, Lars Eggert wrote:

> ones. This means that a hypothetical OWAMP revision can, for  
> example, never use codepoint 5 for a new OWAMP message. If OWAMP and  
> TWAMP are supposed to remain completely separate, then they need two  
> registries (which is what you say below).

The protocols are specified as using different port numbers. Therefore  
OWAMP should be absolutely free to use codepoint 5.

> that OWAMP and TWAMP are tightly related.

I agree.

If you look back in the archives in my review of the TWAMP draft I  
indicated on list what would need to be done to make TWAMP an  
extension of the OWAMP protocol instead of simply a new protocol  
reusing much of the OWAMP message structure.

The authors chose to put TWAMP on a different port instead of making  
TWAMP implementations actually support OWAMP. That is the point at  
which they were 'separated'.

jeff
--
Jeff W. Boote
[email-masked]

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Thu, 3 Apr 2008 09:43:27 -0700

Hi Jeff,

> -----Original Message-----
> From: Jeff W. Boote [mailto:[email-masked]] 
> Sent: Thursday, April 03, 2008 9:12 AM
> To: Murtaza Chiba (mchiba)
> Subject: Re: Question on encrypting the start-time field
> 
> Hi Murtaza,
> 
> On Apr 2, 2008, at 7:20 PM, Murtaza Chiba (mchiba) wrote:
> 
> > Hi Jeff,
> > 	OWAMP mentions that the Start-Time field in the 
> Server-Start message 
> > is to be encrypted in the authenticated and encrypted modes.
> > Since it is only 8 octets I am assuming that it is to be 
> encrypted in
> > the ECB mode and not the CBC mode.   Is that correct?
> 
> This is discussed in section 3.1, page 10 (last para) - page 11(first
> para):
> 
>     Start-Time is a timestamp representing the time when the current
>     instantiation of the server started operating.  (For example, in a
>     multi-user general purpose operating system, it could be the time
>     when the server process was started.)  If Accept is 
> non-zero, Start-
>     Time SHOULD be set so that all of its bits are zeros.  In
>     authenticated and encrypted modes, Start-Time is encrypted as
>     described in Section 3.4, "OWAMP-Control Commands", 
> unless Accept is
>     non-zero.  (Authenticated and encrypted mode cannot be 
> entered unless
>     the control connection can be initialized.)
> 
> Now if you read that forward reference to section 3.4:
> 
>     In authenticated or encrypted mode (which are identical as far as
>     OWAMP-Control is concerned, and only differ in OWAMP-Test), all
>     further communications are encrypted with the AES 
> Session-key (using
>     CBC mode) and authenticated with HMAC Session-key.  The client
>     encrypts everything it sends through the just-established OWAMP-
>     Control connection using stream encryption with Client-IV 
> as the IV.
>     Correspondingly, the server encrypts its side of the 
> connection using
>     Server-IV as the IV.
> 
>     The IVs themselves are transmitted in cleartext.  
> Encryption starts
>     with the block immediately following the block containing the IV.
>     The two streams (one going from the client to the server and one
>     going back) are encrypted independently, each with its own IV, but
>     using the same key (the AES Session-key).
> 

Thanks for the clarification,  so the Start-Time is encrypted in CBC
mode and sent in the Server-Start message.   The HMAC in the first
Accept-Session message also includes the Start-Time field in the HMAC
calculation.  That puts a requirement to maintain state and also puts a
processing distinction between the first Accept-Session and the rest if
multiple Request-Sessions are received by the Server.   I do see that it
does provide a confirmation of the decoded value, why was a HMAC not
added to the Server-Start message itself?   That way each message would
have been a distinct unit.

> Therefore 'encrypted stream' starts immediately following the 
> IV. CBC mode from there until communication ends.
> 

	So is the IV only used during the Server-Start message and the
rest of the stream is encrypted using the last ciphertext from the
previous message?

Thanks,
-Murtaza

> Also relevant to this is the fact that this block is included 
> in the computation of the HMAC, even though the value of the 
> HMAC does not end up getting sent until the next message. See 
> section 3.2:
> 
>     Each HMAC sent covers everything sent in a given
>     direction between the previous HMAC (but not including 
> it) and up to
>     the beginning of the new HMAC.  This way, once encryption 
> is set up,
>     each bit of the OWAMP-Control connection is authenticated 
> by an HMAC
>     exactly once.
> 
> jeff
> 
> P.S. Can we keep protocol clarification questions on list? 
> This would ensure that it gets archived, and therefore 
> someone else can more easily find the answers later. Also, it 
> would allow more objective others to decide if any of these 
> clarifications warrant an errata.
> --
> Jeff W. Boote
> [email-masked]
> 
> 
> 
> 
>

---

From: "Jeff W. Boote" <[email-masked]>
Date: Thu, 3 Apr 2008 11:44:50 -0600

> have been a distinct unit.

To be honest, it was an oversight. We did not originally use an HMAC  
in the protocol, it was added later after our first security review.  
We forgot to add a field to this message and we didn't notice until  
after the RFC had already been approved.

The only downside to this problem is that you can't validate the 'up  
time' of the daemon until after making another request. There is no  
real security risk here so we decided not to mess with it. We only  
added the 'up time' field as a convenience anyway, it is not required  
for the protocol to work. This is not ideal, but it is not bad either.

BTW. You already have to save state across messages for the CBC mode  
so saving state for the HMAC as well is not that big of a deal.  
(Although I sympathize, I noticed this oversight when I was adding the  
HMAC code into our implementation and did not originally have the HMAC  
state variables saved across the functions handling individual  
messages.)

> rest of the stream is encrypted using the last ciphertext from the

Yes.

jeff
--
Jeff W. Boote
[email-masked]

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Thu, 3 Apr 2008 11:31:29 -0700

> Sent: Thursday, April 03, 2008 10:45 AM
> Cc: IETF IPPM WG
> > calculation.  That puts a requirement to maintain state and 
> also puts 
> > a processing distinction between the first Accept-Session 
> and the rest 
> > if
> To be honest, it was an oversight. We did not originally use 
> an HMAC in the protocol, it was added later after our first 
> security review.  
> We forgot to add a field to this message and we didn't notice 
> until after the RFC had already been approved.
> 
> The only downside to this problem is that you can't validate 
> the 'up time' of the daemon until after making another 
> request. There is no real security risk here so we decided 
> not to mess with it. We only added the 'up time' field as a 
> convenience anyway, it is not required for the protocol to 
> work. This is not ideal, but it is not bad either.
> 
> BTW. You already have to save state across messages for the 
> CBC mode so saving state for the HMAC as well is not that big 
> of a deal.  
> (Although I sympathize, I noticed this oversight when I was 
> adding the HMAC code into our implementation and did not 
> originally have the HMAC state variables saved across the 
> functions handling individual
> messages.)

Well, the real problem I see with this is that the there can be no
concurrent processing of messages within a connection if the CBC mode
spans messages.  Of course the RFC precludes this, but it would really
be nice if the CBC mode were limited to exchanges for a given SID so
that parallel processing could be done across SIDs instead of forcing a
new connection.  :(

-Murtaza

> 
> >> Therefore 'encrypted stream' starts immediately following 
> the IV. CBC 
> >> mode from there until communication ends.
> >>
> >
> > 	So is the IV only used during the Server-Start message 
> and the rest 
> > of the stream is encrypted using the last ciphertext from 
> the previous 
> > message?
> 
> Yes.
> 
> jeff
> --
> Jeff W. Boote
> [email-masked]
> 
> 
> 
> 
>

---

From: "Jeff W. Boote" <[email-masked]>
Date: Thu, 3 Apr 2008 12:56:37 -0600

> that parallel processing could be done across SIDs instead of  

TCP is a stream protocol. OWAMP-Control is over TCP. You can't  
parallelize the reading/writing of a stream socket. Given this, I  
don't see any benefit to confusing the encryption by making it  
stateful relative to SID. It is stateful with respect to the stream.

jeff
--
Jeff W. Boote
[email-masked]

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Thu, 3 Apr 2008 12:35:59 -0700

> Sent: Thursday, April 03, 2008 11:57 AM
> > that parallel processing could be done across SIDs instead 
> of forcing 
> > a new connection.  :(
> 
> TCP is a stream protocol. OWAMP-Control is over TCP. You 
> can't parallelize the reading/writing of a stream socket. 

Yes, but what the stream looks like can be decided by the application.
It would be nice to have the capability to do the
Request-Session->Start-Session->Stop-Session for multiple SIDs in
parallel.   Instead of the current method
Request-Session(+)->StartAll-Sessions->StopAll-Sessions.

-Murtaza

> Given this, I don't see any benefit to confusing the 
> encryption by making it stateful relative to SID. It is 
> stateful with respect to the stream.
> 
> jeff
> --
> Jeff W. Boote
> [email-masked]
> 
> 
> 
> 
>

---

From: Al Morton <[email-masked]>
Date: Wed, 16 Apr 2008 17:37:18 -0400

At 11:11 AM 3/17/2008, Henk Uijterwaal wrote:
>This concludes the WGLC for this draft.  Two issues were raised on the
>list.  We'll ask the authors to respond to those on the list and to
>include fixes in the draft.  After that we'll move the document forward.

The new issues list seems to have stopped growing for now,
so (without discussing any resolutions among co-authors, yet)
the text below lists & addresses Murtaza's comments
with four areas identified for "ACTION" in the TWAMP text.

(Thanks Murtaza, and thanks to Jeff for the OWAMP clarifications).

Lars' AD review is next...
Al

>At 02:02 PM 3/10/2008, Murtaza Chiba (mchiba) wrote:
>
>While on the subject, the section 4.2.1 perhaps needs some
>reconsideration.   It seems that only the first 16 bytes are covered in
>the authenticated mode, this leaves the Sender Sequence number open to
>manipulation.

That's the trade-off between Authenticated mode vs. Encrypted mode.

>For the encrypted mode, one paragraph mentions first 96 Octets are
>encrypted, however, another paragraph mentions that the HMAC only covers
>the portion encrypted which is 32 bytes.

The portion of test packet covered by HMAC is 32 octets in Encrypted *mode*.
AES-CBC covers 96 octets (encryption).

>At 04:09 PM 3/25/2008, Murtaza Chiba (mchiba) wrote:
>Some more questions on TWAMP draft.
>
>Q1) Section 3.8 Stop Sessions mentions that command can only be sent by
>the Session-Sender.   I believe the authors meant Control-Client as the
>Session-Sender does not exchange a control command.

ACTION
 >>>Yes (editorial fix)

>Q2) In the same section it mentions that NO session description record
>can be sent, however, it also mentions that the Next SeqNo and Number of
>Skip Ranges MUST be set to 0 and those are part of the session
>description record!   I am assuming the authors ONLY meant to exclude
>the no. Skip Ranges record.

The statement above appears to be correct,
the header of the session description
record is needed to convey the SID of the session to stop.
ACTION
 >>>>It appears we need to clarify the text in 3.8.
We have to clarify that TWAMP Stop-Sessions is like Start-Sessions,
neither has SID and therefore no ability to stop individual test sessions.

Otherwise, NO sessions would be stopped (because it is valid in OWAMP
to send Stop-Sessions Command with zero session description records
and apparently this would not affect any sessions?)
BUT, OWAMP also has text that indicates each Session that has not
been stopped MUST be counted in "Number of Sessions" field and therefore
(the paragraph above that text requires) that every active session
have a session description record (see page 22).
Thus, it appears that the Stop-Session Command stops ALL active sessions.

>Q3) Is it possible to add a SID to a Start-Sessions message?   That
>would help limit the meaning of Active to be per SID allowing for
>different SIDs to be started and stopped on demand.   Sometimes one may
>want to start a Test Stream in response to an observed network
>behaviour.

It would be a new feature.
Possible to add to draft-morton-ippm-more-twamp-...

>Q4) If the above is acceptable then I propose adding a
>Control-Command-type field to all response messages and hence the Accept
>field should be the second field.  It also entails adding a SID in the
>Requests and Responses.

More on the Q3 Q4 topic to add SID to Start Sessions:
At 11:55 AM 3/26/2008, Murtaza Chiba (mchiba) wrote:
>Hi Jeff,
>         If the protocol wants to optimize on starting all test-streams
>at once then a flag can be added to indicate ALL or can be indicated by
>a SID == 0.   Start-Sessions can also include multiple SIDs to allow for
>starting particular sessions.
>
>
>At 03:15 PM 3/28/2008, Murtaza Chiba (mchiba) wrote:
>Another clarification question.
>
>For Test packets the draft is not clear on the order of encryption and
>authentication.   One can assume that the intent was to first encrypt
>and then authenticate the fields which is the reverse of Control
>packets.   It would be nice to see clarification text in the section
>4.2.1 of TWAMP and section 4.1.2 of OWAMP.

ACTION
 >>>HMAC is first, then Encryption.

At 04:50 PM 3/31/2008, Jeff W. Boote wrote:
>On Mar 31, 2008, at 1:42 PM, Murtaza Chiba (mchiba) wrote:
> >
> > Yes, but as I said, in authenticated mode the HMAC could be purely for
> > data integrity not security concerns.
>
>The purpose of authenticated mode is to allow data integrity and
>security just like encrypted mode. However, we wanted to make the
>measurements as accurate as possible. So, the timestamp portion of the
>packet is not encrypted in authenticated mode, therefore you are not
>timing how long it takes to encrypt the packet AND then send it. You
>are able to exclude the encryption time from this. In fully encrypted
>mode, you end up including encryption time in your measurement. Anyone
>'snooping' on those packets is only able to see the 'send' timestamp,
>not the sequence number. This is a trade-off situation.
>
> > Besides the concern for cracking is inconsistent with the Command
> > exchange authenticated mode that has no encryption.   Which leads
> > one to
> > believe that authenticated mode is purely for integrity check.
> > Although, I agree that there will be fewer command exchanges, however,
> > admins tend to have same passwords across all devices!
>
>What makes you say that there is no encryption? There is no difference
>between authenticated mode and encrypted mode in the control
>communication. And in the test packet format, the first block of the
>packet is encrypted in both authenticated mode and encrypted mode.

ACTION
***** IMPORTANT POINT (possibly make this clear in the text) *****

>The *only* thing different from authenticated mode and encrypted mode is
>that the second block of the test packets are not encrypted in
>authenticated mode. And that is only to permit the timestamp to be
>fetched after encryption for the sender.
>
>jeff

>in the section on starting Test Streams.

Yes, the text in section 3.5 describing the Timeout Field
confirms the latter.

>seems that all sessions with a Request-Session-Ack have to be stopped.

Yes. (see Q2 above)

>Number of Packets are to be set to 0!

(see Q2 above)

>octets for encrypted mode reflected packets.

As above, the portion covered by HMAC is 32 octets in Encrypted *mode*.

>since if that is not protected it can lead to tampered roundtrip

That's the trade-off of Authenticated mode vs. Encrypted mode.

>Also, should start messages include SIDs?

That would have to be a new feature, it would need to address
the points below, but possible to add to draft-morton-ippm-more-twamp-...

At 03:35 PM 4/3/2008, Murtaza Chiba (mchiba) wrote:
> > > that parallel processing could be done across SIDs instead of forcing
> > > a new connection.  :(
> >

---

From: Al Morton <[email-masked]>
Date: Fri, 18 Apr 2008 15:43:39 -0400

Lars,

Thanks for the detailed review, you've prompted many
valuable improvements.  My responses are below, and a
revised draft will follow shortly.

If anyone replies to this message, please excerpt the
relevant section and change the Subject line, thanks!

The primary open issue requiring more discussion is
TWAMP Light, as you anticipated.  I have suggested one
way forward, but would like to hear other opinions, too.

regards,
Al

>because it is still being discussed.

Sorry for the delay replying, many standards bodies I follow
became active in parallel...

>    Nit: s/Measurment/Measurement/ (everywhere in the footer)
OK

>    (In other words, cut "IP Performance Metrics (IPPM) working group's".)
OK

>    See above - rephrase to not talk about IPPM.
OK

>    I don't quite understand what you mean by "time accuracy is less

Revised sentence:
"Two-way measurements are common in IP networks, primarily because
synchronization between local and remote clocks is unnecessary for
round-trip delay, and measurement support at the remote end may be
limited to a simple echo function."

>    This section is almost word-by-word identical to a big chunk of

Yes, this is just a summary of 1.2.  What's really needed here is
an outline for the typical operation of the protocol(s). This should
be understandable since all the entities and protocols have been
introduced in 1.2.  I'll give that a try in the next draft.

>    these OWAMP control messages? If yes, say so with RFC2119 terms.

It is simpler to say something definitive about the Fetch-Session msg:
"One such exception is the Fetch Session command, which is not used in TWAMP."
(Actually, this sentence is part of the 1st paragraph, and just extends
the ways in which TWAMP differs from OWAMP.)

>    octet codes 2-4 for other commands.)

After deleting all the mis-leading stuff above, we have a paragraph
introducing the Command Number Field. Then this new paragraph:

"The Command Number value of 5 indicates that this is a
Request-TW-Session Command, and the Server MUST interpret
this command as a request for a two way test session using the
TWAMP-Test protocol."

>    ...You should make sure that you
good catch, thanks.

>  >     In TWAMP, the first octet is referred to as the Command Number, and
>  >     the Command Number is a recognized extension mechanism. Readers are
>    addition to TWAMP also covers OWAMP, it should update RFC4656, if only

Although TWAMP is highly dependent on messages and procedures that
OWAMP defined, the registry is only for TWAMP. For example, we made
OWAMP's Request-Session command number (1) Forbidden in TWAMP.
So I'm inclined to agree with Jeff here, TWAMP and OWAMP will be
administrated separately, but it's less about a choice we authors made
and more about the recognition that there will need to be TWAMP-only
implementations (it simply wasn't practical to have TWAMP-only hosts
as an extension of the existing RFC - OWAMP would have to be mandatory).

>    s/SHOULD/MUST/ (or else explain in which cases the SHOULD may
OK, MUST

*** Also, that should be the Accept-Session message, not the Server Start...

>  >     since the Session-Reflector will both receive and send packets, and
>  >     the roles are established according to which host initiates the TCP

Yes, it's an improperly formed command. So, now we have:
"...The server MUST interpret any non zero value as an improperly
formatted command, and MUST respond with the Accept field set
to 3 (meaning "Some aspect of request is not supported")
in the Accept-Session message."

>    This seems to be a difference to OWAMP. Any particular reason why?

It's a convenience, AFAIK, it just simplifies user configurations.
TWAMP light wouldn't use the Request-TW-Session message.
But I note that the TWAMP entities named above should be the
Control-Client and the Server, so fixed that.

>  >     Point (DSCP) as defined in [RFC2474].  The same value of DCSP
OK

>  >     Session-Reflector such as sequence number, timestamp, and TTL. As

Paragraph 4 in section 3.5 (06 version) covers this case: the
command is rejected with code 3. However, this repeated attention
to the Fetch-Session command leads me to try some very definitive
clarifications:

Section 3.4:  List the commands that ARE supported, and say that
OWAMP's Request-Session and Fetch-Session are NOT used in TWAMP.

Section 3.9:  The text isn't quite as clear as it could be, so
I've suggested some modifications:
"The purpose of TWAMP is measurement of two way metrics.
Two way measurement methods do not require packet level data
to be collected by the Session Reflector (such as sequence number,
timestamp, and TTL) because this data is communicated in the "reflected"
test packets.  As such the protocol does not require the retrieval of
packet level data from the Server and the OWAMP Fetch Session command
is not used in TWAMP."

Section 8.4:  Reserve the Fetch-Session command number for
something else in TWAMP, but don't add Fetch-Session to the
TWAMP control command number registry.

>    and not the specification)

Let's use this clarification:
"Implementation note: Naturally, the key schedule for each TWAMP Test
session MUST be set up at most once per session,
not once per packet."
(Note: the original sentence is the same in OWAMP)

>    Nit: s/Session-Reflctor/Session-Reflector/
OK

>    interoperate without knowing which variant the other side is using.

I agree, this material describes a case where a sub-set of the
TWAMP spec is used (just the TWAMP-Test protocol).

>    If the two variants are desired by the WG, they need to be described in

Variant discovery will be hard, because the TWAMP Light variant does not
share the control protocol, just the test packet format...

Personally, I think it might be better to move TWAMP Light to
an appendix (informative). "Light" raises a number of Security concerns
that we were asked to address. We could move them to the
Appendix and have a much stronger Security Considerations section.

>    use one term consistently throughout the document.

Made the changes in Section 8. and 3.5

>    Reserved or Forbidden values are received.

I think the 4th paragraph of section 3.5 covers this
(since they are unexpected numbers), but I'll add a sentence to clarify:
"Command numbers that are Forbidden (and possibly numbers
that are Reserved) are unexpected."

>(Is there a difference?)

Yes, a forbidden number is always unexpected, but a future
implementation/version might use a reserved number. I think
the above text makes this distinction...

>    s/draft-ietf-ippm-owdp-11.txt/RFC 4656/
OK

>    s/RFC 2474/RFC 2434/ (copy&paste error?)
OK

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Mon, 21 Apr 2008 15:02:36 -0700

Thanks for the responses, Al.   Some more comments inline at [MSC]. 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Al Morton
> Sent: Wednesday, April 16, 2008 2:37 PM
> To: Henk Uijterwaal
> Cc: IETF IPPM WG
> Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt
> 
> The new issues list seems to have stopped growing for now, so 
> (without discussing any resolutions among co-authors, yet) 
> the text below lists & addresses Murtaza's comments with four 
> areas identified for "ACTION" in the TWAMP text.
> 

[MSC] So it seems the purpose of the Authenticate mode is to verify the
sender only.   Then the authenticate mode seems a bit strange and
unnecessary!   With TWAMP/OWAMP one would expect the primary field is
Timestamp from which most statistics are derived and to leave it open to
manipulation, IMO, defeats the purpose of securing the protocol.   So
maybe the mode should be removed from both TWAMP and OWAMP?   As it is
the usage of the term authenticated is misleading.

> >encrypted, however, another paragraph mentions that the HMAC only 
> >covers the portion encrypted which is 32 bytes.
> 

[MSC] That seems contradictory to the statement "HMAC in TWAMP-Test only
covers the part of the packet that is also encrypted."  So, if 96 bytes
are encrypted then 96 bytes need to be covered by HMAC.

> >can be sent, however, it also mentions that the Next SeqNo 
> and Number 
> >of Skip Ranges MUST be set to 0 and those are part of the session
> The statement above appears to be correct, the header of the 
> session description record is needed to convey the SID of the 
> session to stop.
> ACTION
> We have to clarify that TWAMP Stop-Sessions is like 
> Start-Sessions, neither has SID and therefore no ability to 
> stop individual test sessions.
> 
> Otherwise, NO sessions would be stopped (because it is valid 
> in OWAMP to send Stop-Sessions Command with zero session 
> description records and apparently this would not affect any 
> sessions?) BUT, OWAMP also has text that indicates each 
> Session that has not been stopped MUST be counted in "Number 
> of Sessions" field and therefore (the paragraph above that 
> text requires) that every active session have a session 
> description record (see page 22).

[MSC] Since TWAMP is still a draft may be we have room to add the
functionality.   Not sure why its being addressed by a separate draft.

> >Control-Command-type field to all response messages and hence the 
> >Accept field should be the second field.  It also entails 
> adding a SID 
> >in the Requests and Responses.
> 
> 
> > > Yes, but as I said, in authenticated mode the HMAC could 
> be purely 
> > > for data integrity not security concerns.
> >
> > > Although, I agree that there will be fewer command exchanges, 
> > > however, admins tend to have same passwords across all devices!
> >
> >The *only* thing different from authenticated mode and 
> encrypted mode 
> >is that the second block of the test packets are not encrypted in 
> >timeout only effective after the Stop sessions is received or is it 
> >that even before the stop sessions the Reflector is to 
> reject packets with
> >I interpret it as the former rather than the latter, that 
> is, timeout 
> >is ONLY effective after a stop sessions is received, which is as 
> >mentioned in the section on starting Test Streams.
> 

[MSC] I think you mean that the former is true and that the Timeout is
only applicable after receiving a Stop-Sessions message.

> >Number of Packets are to be set to 0!

[MSC] The clarification was not very clear however, which of the
following two packet formats are you suggesting is the correct one?

1.)
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      3        |    Accept     |              MBZ              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Number of Sessions                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        MBZ (8 octets)                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

     |                        SID (16 octets)                        |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Next Seqno                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Number of Skip Ranges                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       HMAC (16 octets)                        |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Or as :

2.)
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      3        |    Accept     |              MBZ              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Number of Sessions                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        MBZ (8 octets)                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       HMAC (16 octets)                        |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> As above, the portion covered by HMAC is 32 octets in 

[MSC] See response above

> That's the trade-off of Authenticated mode vs. Encrypted mode.

[MSC] See response above

> draft-morton-ippm-more-twamp-...

[MSC] Again, since TWAMP is still a draft why address via new draft
instead of making the enhancements to the current TWAMP draft?

Thanks,
-Murtaza

> > > > concurrent processing of messages within a connection 
> if the CBC 
> > > > mode spans messages.  Of course the RFC precludes this, but it 
> > > > would really be nice if the CBC mode were limited to 
> exchanges for 
> > > > a given SID so that parallel processing could be done 
> across SIDs 
> > > > instead of forcing a new connection.  :(
> > >
> > > parallelize the reading/writing of a stream socket.
> >
> encryption by 
> > > making it stateful relative to SID. It is stateful with 
> respect to 
> > > the stream.
> > >
> > > jeff
> > > --
>

---

From: Al Morton <[email-masked]>
Date: Mon, 21 Apr 2008 21:43:10 -0400

Replies in-line,
Al
At 06:02 PM 4/21/2008, Murtaza Chiba (mchiba) wrote:
>...

The draft explains the main reason for Authenticated mode, to keep
the HMAC and encryption process from affecting the timestamp accuracy.

> > The portion of test packet covered by HMAC is 32 octets in
> > Encrypted *mode*. AES-CBC covers 96 octets (encryption).
> >
>

The numbers override the grammar.

>...

Here's why:  Feature creep.  We stopped adding features,
and have really just been clarifying the text since last
September...

>...

Don't worry, the revised sentence in the draft will be clear.
It's this one, with no SID or other session description info.

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 22 Apr 2008 07:40:34 +0200

Murtaza,

> functionality.   Not sure why its being addressed by a separate draft.

At some point last year, we decided to finalize the current document and
give everybody interested in implementing a stable spec.  At that time,
there were no requests for additional features but if they were needed,
they could be addressed in a follow-up document.

IMHO, this is still true: let's finish what we have and put new work
in a second document.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Is one of the choices leaving the office open?
                                       Alan Greenspan on the next elections
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Tue, 22 Apr 2008 15:18:24 -0700

Replies at [MSC2] 

> From: Al Morton [mailto:[email-masked]] 
> Sent: Monday, April 21, 2008 6:43 PM
> To: Murtaza Chiba (mchiba); Henk Uijterwaal
> Cc: IETF IPPM WG
> Subject: RE: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt
> 
> Replies in-line,
> Al
> The draft explains the main reason for Authenticated mode, to 
> keep the HMAC and encryption process from affecting the 
> timestamp accuracy.
> 

[MSC2] The security only serves the purpose of verifying where the
packet originated from as it is wide open for manipulation of the most
critical piece of data for the protocol.   Therefore its as good as no
security and hence I would vote +1 to remove it!

> > > The portion of test packet covered by HMAC is 32 octets 
> in Encrypted 
> > > *mode*. AES-CBC covers 96 octets (encryption).
> > >
> >
> >[MSC] That seems contradictory to the statement "HMAC in TWAMP-Test 
> >only covers the part of the packet that is also encrypted."  
> So, if 96 
> >bytes are encrypted then 96 bytes need to be covered by HMAC.
> 

[MSC2] Can we add an action item to correct the grammar?

> Here's why:  Feature creep.  We stopped adding features, and 
> have really just been clarifying the text since last September...
> 

[MSC2] okay, will respond to this in the next mail from Henk.

Thanks,
-Murtaza

> >      |      3        |    Accept     |              MBZ     
>          |
> >      |                      Number of Sessions              
>          |
> >      |                        MBZ (8 octets)                
>          |
> >      |                                                      
>          |
> >      |                                                      
>          |
> >      |                       HMAC (16 octets)               
>          |
> >      |                                                      
>          |
> >      |                                                      
>          |

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Tue, 22 Apr 2008 15:22:22 -0700

Hi Henk,
	Response inline. 

> From: Henk Uijterwaal [mailto:[email-masked]] 
> Sent: Monday, April 21, 2008 10:41 PM
> Cc: Al Morton; IETF IPPM WG
> At some point last year, we decided to finalize the current 
> document and give everybody interested in implementing a 
> stable spec.  At that time, there were no requests for 
> additional features but if they were needed, they could be 
> addressed in a follow-up document.
> 
> IMHO, this is still true: let's finish what we have and put 
> new work in a second document.

If the original TWAMP draft had a clear path for extension I would have
no problems with the above statement.   As it stands now there is no
version number and hence there is no way to judge capabilities in a
mixed environment.

-Murtaza

---

From: Al Morton <[email-masked]>
Date: Tue, 22 Apr 2008 23:38:27 -0400

At 06:22 PM 4/22/2008, Murtaza Chiba (mchiba) wrote:
>no problems with the above statement.

There are two clear extension mechanisms, the Mode field
(like in OWAMP), and the Control Command Number (TWAMP-only).

>  As it stands now there is no

We might be able to use some bits that are currently MBZ for this.

Does anyone else see a strong need for an explicit version number?
Al

---

From: "Jeff W. Boote" <[email-masked]>
Date: Tue, 22 Apr 2008 21:47:54 -0600

> Does anyone else see a strong need for an explicit version number?

No. I guess it would not be unreasonable to make the extension mechanism more 
clear in the draft however - perhaps an example? I did think about doing this to 
the owamp draft - but no one had issue with it so it did not seem needed. (To be 
clear, I believe the mechanism itself is adequate.)

jeff

---

From: Al Morton <[email-masked]>
Date: Wed, 23 Apr 2008 09:26:50 -0400

At 11:47 PM 4/22/2008, Jeff W. Boote wrote:
>No. I guess it would not be unreasonable to make the extension 
>mechanism more clear in the draft however - perhaps an example? I 
>did think about doing this to the owamp draft - but no one had issue 
>with it so it did not seem needed. (To be clear, I believe the 
>mechanism itself is adequate.)
>
>jeff

The TWAMP-Control Command Number for Request-TW-Session (the new name)
is itself an example of extension over the OWAMP numbers, and
draft-morton-more-twamp-00.txt is an example of the Modes field extension.

It makes sense to highlight the recognized extension mechanisms in the
(new) Protocol Overview section, so that's what I'll attempt.

Al

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Wed, 23 Apr 2008 10:12:44 -0700

Al and Jeff,
	What I meant is that there is no way to figure out which
extensions the client and server are supporting without actually sending
a message and seeing if it is rejected!   
	IMHO there is more than just textual clarification that is
required.  

-Murtaza 

> Sent: Wednesday, April 23, 2008 6:27 AM
> To: Jeff W. Boote
> Cc: Murtaza Chiba (mchiba); Henk Uijterwaal; IETF IPPM WG
> >>>If the original TWAMP draft had a clear path for extension I would 
> >>>have no problems with the above statement.
> >>There are two clear extension mechanisms, the Mode field (like in 
> >>OWAMP), and the Control Command Number (TWAMP-only).
> >>
> >mechanism more clear in the draft however - perhaps an 
> example? I did 
> >think about doing this to the owamp draft - but no one had 
> issue with 
> >it so it did not seem needed. (To be clear, I believe the mechanism 
> >itself is adequate.)
> >
> >jeff
> 
> The TWAMP-Control Command Number for Request-TW-Session (the 
> new name) is itself an example of extension over the OWAMP 
> numbers, and draft-morton-more-twamp-00.txt is an example of 
> the Modes field extension.
>

---

From: Al Morton <[email-masked]>
Date: Wed, 23 Apr 2008 16:57:51 -0400

>a message and seeing if it is rejected!

That's not necessarily the case, take this as an example:
http://tools.ietf.org/html/draft-morton-ippm-more-twamp-00#section-3.1

The Server indicates the modes it will support in the Server Greeting.
The Control-Client cannot use an unsupported mode.

>         IMHO there is more than just textual clarification that is

Understood.  Do others have opinions?
Al