Subject: [ippm] Alissa Cooper's Discuss on draft-ietf-ippm-2679-bis-04: (with DISCUSS and COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 18 Aug 2015 12:14:31 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-ippm-2679-bis-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-2679-bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am confused about the last sentence in this methodology step in Section
3.6:

"+ At the Src host, select Src and Dst IP addresses, and form a test
   packet of Type-P with these addresses.  Any 'padding' portion of the
   packet needed only to make the test packet a given size should be
   filled with randomized bits to avoid a situation in which the
   measured delay is lower than it would otherwise be due to compression
   techniques along the path.  Note that use of transport layer
   encryption will counteract the deployment of network-based analysis
   and may reduce the adoption of network-based payload optimizations
   like compression."

I don't understand what is implied about the relationship between
transport layer encryption and one-way delay measurements. I thought the
metric defined in this document was generally used for end-to-end
measurement of delay, so I don't understand what "network-based analysis"
has to do with this methodology step. Is the implication that if the
measurement packet is encrypted at the transport layer that delay will
change? If that is true, isn't the metric itself agnostic to that
consideration -- that is, couldn't that be precisely what the person
doing the measurements wants to measure? I could quibble with the
conclusions of the note itself (e.g., increased transport layer
encryption may change but not necessarily reduce network-based "analysis"
of various sorts), but mainly I do not understand how it relates to the
specification of the metric.

Unfortunately the rationale given in Section 1 ("Added text recognizing
the impending deployment of transport layer encryption in section 3.6")
does not clarify this either. What impending deployment is this
referencing?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

>From Section 6:

"The privacy concerns of network measurement are limited by the active
   measurements described in this memo.  Unlike passive measurements,
   there can be no release of existing user data."

I realize this is text from RFC 2679, but I think it would be good to
update it to reflect what has been learned since the publication of that
document. The mere fact that a host is involved in conducting
measurements could well be considered privacy-sensitive in some contexts.
And a collection of measurements about a host, even active measurements,
could leak information about the host's connectivity/availability/etc. if
not appropriately safeguarded. I don't think this changes the protocol
requirements for this document, but I do think the text above should note
these aspects (perhaps similar to how it's done in
<https://tools.ietf.org/html/draft-ietf-lmap-framework-14#section-8.3>).
It's not quite correct to say there can be no release of existing user
data.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 18 Aug 2015 23:07:03 -0400

Hi Alissa,
Thanks for your review, replies below.
Al

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Alissa Cooper
...
> Subject: [ippm] Alissa Cooper's Discuss on draft-ietf-ippm-2679-bis-04:
> (with DISCUSS and COMMENT)
> 
...
> measurement of delay, so I don't understand what "network-based
> analysis" has to do with this methodology step. 
[ACM] 
The methodology calls for a random payload in an attempt to measure
the delay on an a path without effects of network-based compression 
(if it is present).

> Is the implication that if the
> change? 
[ACM] 
No, not if the methodology recommendation of a random payload is followed.

On the other hand, if end-to-end encryption of user traffic becomes 
commonplace, then network-based compression will see less deployment
because it has little benefit, and the recommendation for random 
payload will be unnecessary. That's the implication.

> If that is true, isn't the metric itself agnostic to that
[ACM] 
Ironically, I added the last sentence above during review of this draft,
after addressing your comment on what is now RFC 7312,
which says:

3.1.2.  Test Packet Payload Content Optimization

   The aim for efficient network resource use has resulted in deployment
   of server-only or client-server lossless or lossy payload compression
   techniques on some links or paths.  These optimizers attempt to
   compress high-volume traffic in order to reduce network load.  Files
   are analyzed by application-layer parsers, and parts (like comments)
   might be dropped.  Although typically acting on HTTP or JPEG files,
   compression might affect measurement packets, too.  In particular,
   measurement packets are qualified for efficient compression when they
   use standard plain-text payload.  We note that use of transport-layer
   encryption will counteract the deployment of network-based analysis
   and may reduce the adoption of payload optimizations, however.

I'll try to clarify the text in section 3.6, but feel free to make a
suggestion yourself.

> could leak information about the host's connectivity/availability/etc.
> if not appropriately safeguarded. I don't think this changes the
> protocol requirements for this document, but I do think the text above
> should note these aspects (perhaps similar to how it's done in
[ACM]
I'll replace the sentence above with the privacy paragraph from 
section 6 of RFC 7312, including the reference to the LMAP Framework.
http://tools.ietf.org/html/rfc7312#section-6

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 19 Aug 2015 15:55:09 -0700

Hi Al,

> payload will be unnecessary. That's the implication.

Ok, got it. I’m not sure anything actually needs to be noted here beyond what is already written in RFC 7312. It seems like you would want implementations to randomize the padding since measurement packets may or may not get encrypted at the transport layer. So I would suggest deleting the sentence from 3.6. 

>   and may reduce the adoption of payload optimizations, however.

Ok, I understand this now with the larger context provided in RFC 7312. 

Thanks,
Alissa

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 20 Aug 2015 07:53:30 -0400

> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Wednesday, August 19, 2015 6:55 PM
...
> 
> Ok, got it. I'm not sure anything actually needs to be noted here beyond
> what is already written in RFC 7312. It seems like you would want
> implementations to randomize the padding since measurement packets may
> or may not get encrypted at the transport layer. So I would suggest
> deleting the sentence from 3.6.
> 
> 
[ACM] 
That works for me, will also delete the corresponding change note
in section 1.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 21 Aug 2015 09:29:18 -0500

Hi, Alissa,

> That works for me, will also delete the corresponding change note

Al has submitted a -05 that should address your Discuss. Could you take a
peek at it, and let us know?

Thank you,

Spencer