Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt

From: Al Morton <[email-masked]>
Date: Mon, 10 Mar 2008 12:02:08 -0400

At 09:43 AM 2/25/2008, Henk Uijterwaal wrote:
>This is a WGLC for the draft: draft-ietf-ippm-twamp-06.txt
>
>The draft has been discussed extensively in this group and appears to
>to be stable by now.  We like to start a WGLC in order to move it forward.
>Please raise any remaining issues by Friday, March 14, 9:00 UTC.

Two Editorial comments have come to my attention:

In section 4.2.1, there's no explicit specification of the
Timestamp format for the new packets defined. One could
guess "same as OWAMP" and you'd be right with most, but...

better to add (after the new formats, page 15) :

Note that all Timestamps have the same format as OWAMP [RFC4656]
as follows:

  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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Integer part of seconds                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Fractional part of seconds                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

The second comment was a suggestion to reverse the order of two
sentences for readability.  I can't seem to find my note saying
exactly which two sentences, but I think they were in section 5.

I'll keep looking,
Al

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

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Mon, 10 Mar 2008 11:02:47 -0700

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.

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.

-Murtaza

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Al Morton
Sent: Monday, March 10, 2008 9:02 AM
To: Henk Uijterwaal; IETF IPPM WG
Cc: Matthew J Zekauskas
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt

In section 4.2.1, there's no explicit specification of the Timestamp
format for the new packets defined. One could guess "same as OWAMP" and
you'd be right with most, but...

Note that all Timestamps have the same format as OWAMP [RFC4656] as
follows:

  0                   1                   2                   3

---

The second comment was a suggestion to reverse the order of two
sentences for readability.  I can't seem to find my note saying exactly
which two sentences, but I think they were in section 5.

I'll keep looking,
Al

---

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

Any clarifications?

-Murtaza 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Murtaza Chiba (mchiba)
Sent: Monday, March 10, 2008 11:03 AM
To: Al Morton; Henk Uijterwaal; IETF IPPM WG
Cc: Matthew J Zekauskas
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt

-Murtaza

-----Original Message-----

  0                   1                   2                   3

---

I'll keep looking,
Al

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 17 Mar 2008 16:11:41 +0100

IPPM Group,

> An URL for the draft is:
>   http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-06.txt

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.

Matt & 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, 25 Mar 2008 13:09:59 -0700

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.

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.

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.   

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.

-Murtaza

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henk Uijterwaal
Sent: Monday, March 17, 2008 8:12 AM
To: Henk Uijterwaal
Cc: IETF IPPM WG
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt

IPPM Group,

Matt & 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
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: "Jeff W. Boote" <[email-masked]>
Date: Wed, 26 Mar 2008 01:28:12 -0600

> want to start a Test Stream in response to an observed network

I believe it is more simple to just open another control-connection in  
this case. That was the solution we decided upon  in OWAMP anyway.

I can see other use cases where it would be advantageous to do as you  
suggest. It probably comes down to determining what the most likely  
use cases are and optimizing based on that. But, I figured I would let  
you know the motivation for why we did it this way in OWAMP. (In fact,  
at the time I suggested something like what you have suggested here.  
In the end, during implementation, I was glad to have it stay more  
simple.)

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

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Wed, 26 Mar 2008 08:55:00 -0700

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.
	IMHO its cumbersome to add multiple connections each time a test
session needs to be started, instead it is better to re-use the open
connection.  It also would be nice if the responses include a
Command-Code, that way the packet type is clearly identified and does
not need to be guessed based on the state.

Thanks,
-Murtaza

-----Original Message-----
From: Jeff W. Boote [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2008 12:28 AM
To: Murtaza Chiba (mchiba)
Cc: Henk Uijterwaal; IETF IPPM WG
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt

I can see other use cases where it would be advantageous to do as you
suggest. It probably comes down to determining what the most likely use
cases are and optimizing based on that. But, I figured I would let you
know the motivation for why we did it this way in OWAMP. (In fact, at
the time I suggested something like what you have suggested here.  
In the end, during implementation, I was glad to have it stay more
simple.)

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

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Fri, 28 Mar 2008 12:15:19 -0700

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.

-Murtaza

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Murtaza Chiba (mchiba)
Sent: Tuesday, March 25, 2008 1:10 PM
To: Henk Uijterwaal
Cc: IETF IPPM WG
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt

-Murtaza

-----Original Message-----

IPPM Group,

Matt & Henk

---

From: "Jeff W. Boote" <[email-masked]>
Date: Fri, 28 Mar 2008 14:01:19 -0600

> 4.2.1 of TWAMP and section 4.1.2 of OWAMP.

I did not go read the TWAMP section to see if the situation is the  
same, but for OWAMP there is no order at all. There are 3 different  
'modes':

open, encrypted, authenticated.

These modes are negotiated in the control connection, and which  
process the individual packets go through is defined based on the  
selected mode. They are independent - there is no order to consider.

The difference between authenticated and encrypted is that the  
timestamp information is sent unencrypted in authenticated mode to  
reduce the amount of time from when the timestamp was retrieved and  
the packet is actually sent. In encrypted mode, the entire data  
segment is encrypted including the timestamp.

Perhaps I'm completely missing the point?

jeff

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

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Fri, 28 Mar 2008 14:59:33 -0700

In encrypted mode is the HMAC field set to 0 for test packets?

-Murtaza

-----Original Message-----
From: Jeff W. Boote [mailto:[email-masked]] 
Sent: Friday, March 28, 2008 1:01 PM
To: Murtaza Chiba (mchiba)
Cc: Henk Uijterwaal; IETF IPPM WG
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt

> 4.2.1 of TWAMP and section 4.1.2 of OWAMP.

I did not go read the TWAMP section to see if the situation is the same,
but for OWAMP there is no order at all. There are 3 different
'modes':

These modes are negotiated in the control connection, and which process
the individual packets go through is defined based on the selected mode.
They are independent - there is no order to consider.

The difference between authenticated and encrypted is that the timestamp
information is sent unencrypted in authenticated mode to reduce the
amount of time from when the timestamp was retrieved and the packet is
actually sent. In encrypted mode, the entire data segment is encrypted
including the timestamp.

jeff

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Murtaza Chiba (mchiba)

> 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
> 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.
>
> -Murtaza
>
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Henk Uijterwaal

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

---

From: "Jeff W. Boote" <[email-masked]>
Date: Fri, 28 Mar 2008 23:39:11 -0600

> In encrypted mode is the HMAC field set to 0 for test packets?

I'm curious why you ask that? Is there something in the RFC that leads  
you think that? (Even if it is not reasonable to change this RFC, I  
would like to understand where we have been unclear.)

I believe this should have been explained by the last paragraph of  
page 31/first paragraph of page 32 of the RFC:

    Implementation note: Naturally, the key schedule for each OWAMP-Test
    session MAY be set up only once per session, not once per packet.
    HMAC in OWAMP-Test only covers the part of the packet that is also
    encrypted.  So, in authenticated mode, HMAC covers the first block
    (16 octets); in encrypted mode, HMAC covers two first blocks (32
    octets).  In OWAMP-Test HMAC is not encrypted (note that this is
    different from OWAMP-Control, where encryption in stream mode is
    used, so everything including the HMAC blocks ends up being
    encrypted).

In all cases in the specification HMAC is computed before encrypting  
blocks (this is only stated earlier in the specification when talking  
about the control communication, but is standard for HMAC use).

So, for the test packets: In authenticated mode, only the first block  
is used to generate the HMAC, and then only the first block is  
encrypted. In encrypted mode, the HMAC is computed using the first two  
blocks, and both of those blocks are encrypted. In both of these cases  
the HMAC field is set to the result of hashing the HMAC key with the  
data in the blocks using the HMAC-SHA1 algorithm as specified.

jeff

> same,
> process
> timestamp

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

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Sat, 29 Mar 2008 17:21:03 -0700

Hello Jeff,
	Response at MSC>	 

-----Original Message-----
From: Jeff W. Boote [mailto:[email-masked]] 
Sent: Friday, March 28, 2008 10:39 PM
To: Murtaza Chiba (mchiba)
Cc: Henk Uijterwaal; IETF IPPM WG
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt

I believe this should have been explained by the last paragraph of page
31/first paragraph of page 32 of the RFC:

MSC> Since the Control exchange uses stream encryption it makes most
sense that the HMAC is calculated before encrypting.   However, for Test
packets, since only part of the packet is being encrypted it is not
clear whether the HMAC is a check for the encrypted packet (that is it
is calculated after encryption) or for the packet before encryption.
If it is a signature for the encrypted packet then one can check
integrity before decrypting and that speeds-up processing, that is
reverse of the process for Control packets.   The other way round, the
packet has to be decrypted first (a more expensive process) and then the
signature needs to be verified.

-Murtaza
 
So, for the test packets: In authenticated mode, only the first block is
used to generate the HMAC, and then only the first block is encrypted.
In encrypted mode, the HMAC is computed using the first two blocks, and
both of those blocks are encrypted. In both of these cases the HMAC
field is set to the result of hashing the HMAC key with the data in the
blocks using the HMAC-SHA1 algorithm as specified.

jeff

> selected mode.

>> ---------------------------------------------------------------------
>> -
>> --
>> ------
>> Henk Uijterwaal                           Email:
>> ---------------------------------------------------------------------
>> -
>> --
>> ------
>>

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

---

From: "Jeff W. Boote" <[email-masked]>
Date: Sun, 30 Mar 2008 15:33:20 -0600

Hi Murtaza,

> signature needs to be verified.

The optimization you suggest is not without a cost. If the data going  
into the HMAC and the result of the HMAC are both transmitted in the  
clear, the HMAC hash function is more susceptible to attack. If this  
level of optimization is required, I suggest using open mode.

If you believe others could be confused by the fact that it is not  
explicitly stated that the HMAC is computed on the non-encrypted  
message contents first (in this part of the RFC), then I would suggest  
submitting an errata for the RFC.

jeff

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

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Mon, 31 Mar 2008 10:24:21 -0700

Hi Jeff, 

> > sense that the HMAC is calculated before encrypting.   
> However, for  
> > Test
> > packet has to be decrypted first (a more expensive process) 
> and then 
> > the signature needs to be verified.
> 
> The optimization you suggest is not without a cost. If the 
> data going into the HMAC and the result of the HMAC are both 
> transmitted in the clear, the HMAC hash function is more 
> susceptible to attack. If this level of optimization is 
> required, I suggest using open mode.
> 

I agree that when using encrypted mode there is a reason to be paranoid
and hence it is preferable to authenticate before encryption.   
How about the authenticated mode?   The reason to use an authenticated
mode could be less to do with security (and hence susceptibility) and
more to do with data integrity.

-Murtaza

> If you believe others could be confused by the fact that it 
> is not explicitly stated that the HMAC is computed on the 
> non-encrypted message contents first (in this part of the 
> RFC), then I would suggest submitting an errata for the RFC.
> 
> jeff
> 
> 
> >
> >
> > -Murtaza
> >
> > encrypted.
> > In encrypted mode, the HMAC is computed using the first two blocks, 
> > and both of those blocks are encrypted. In both of these cases the 
> > HMAC field is set to the result of hashing the HMAC key 
> with the data 
> > in the blocks using the HMAC-SHA1 algorithm as specified.
> >
> > jeff
> >
> >>
> >>> For Test packets the draft is not clear on the order of 
> encryption 
> >>> and
> >>> 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
> >>> different SIDs to be started and stopped on demand.   
> Sometimes one
> >>> may
> >>> Accept field should be the second field.  It also entails 
> adding a 
> >>> SID
> >>
> >>>> The draft has been discussed extensively in this group 
> and appears 
> >>>> to
> >>
> >>> This concludes the WGLC for this draft.  Two issues were 
> raised on 
> >>> the
> >>

---

From: "Jeff W. Boote" <[email-masked]>
Date: Mon, 31 Mar 2008 11:43:42 -0600

Hi Murtaza,

> more to do with data integrity.

Cracking the hash cracks it for the purposes of authenticated mode as  
well. (For all test packets in the session.)

Besides, I think it would be confusing to do it differently in this  
one case, from all other cases in the protocol. I think the intent of  
the RFC was clear and I don't see a good reason to change it. However,  
I have nothing against an errata to make it more clear.

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

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Mon, 31 Mar 2008 12:42:32 -0700

Hi Jeff, 

> Sent: Monday, March 31, 2008 10:44 AM
> data going 
> > I agree that when using encrypted mode there is a reason to be 
> > paranoid and hence it is preferable to authenticate before 
> encryption.
> Cracking the hash cracks it for the purposes of authenticated 
> mode as well. (For all test packets in the session.)
> 

Yes, but as I said, in authenticated mode the HMAC could be purely for
data integrity not security concerns.

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!

-Murtaza

> Besides, I think it would be confusing to do it differently 
> in this one case, from all other cases in the protocol. I 
> think the intent of the RFC was clear and I don't see a good 
> reason to change it. However, I have nothing against an 
> errata to make it more clear.
> 
> jeff
> --
> Jeff W. Boote
> [email-masked]
> 
> 
> 
> 
>

---

From: "Jeff W. Boote" <[email-masked]>
Date: Mon, 31 Mar 2008 14:50:57 -0600

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

> 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. 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
--
Jeff W. Boote
[email-masked]

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Mon, 31 Mar 2008 14:48:01 -0700

> Sent: Monday, March 31, 2008 1:51 PM
> 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.
> 
> 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. 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.
> 

Okay, my bad, coming from an IPSec/crypto background the terms used in
OWAMP are confusing.   In IPSec AH is purely integrity check and ESP is
purely encryption and in crypto textbooks too the terms integrity hash
and encryption have distinct connotations.   One can encapsulate AH
within ESP (or vice versa) to get both.   It is strange that
authenticated mode actually performs encryption too in OWAMP!   Maybe
authenticated mode needs to be renamed to encapsulate the meaning
better?

-Murtaza

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Mon, 31 Mar 2008 23:11:29 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Murtaza Chiba (mchiba)
> Sent: Monday, March 31, 2008 2:48 PM
> To: Jeff W. Boote
> measurement. Anyone 
> > > exchange authenticated mode that has no encryption.   
> Which leads  
> > > one to
> difference 
> and encryption have distinct connotations.  

Sorry, I meant ESP has both and is similar to the encryption term for
the Test stream, but AH is purely authentication and does not entail any
encryption.   It would be better to call the authenticated mode
encrypted-ecb mode and the encrypted mode as encrypted-cbc mode, or
encrypted and encrtyped-timestamp modes respectively.

-Murtaza

 One can encapsulate AH
> authenticated mode needs to be renamed to encapsulate the 
> meaning better?
> 
> -Murtaza
> 
> 
> > jeff
> > --
> > Jeff W. Boote
> > [email-masked]
> > 
> > 
> > 
> > 
> >