Re: [ippm] Seeking advice on encryption requirements for a new measurement protocol

["MORTON JR., AL" <[e-mail]>]

Thanks for your thoughts and helpful questions, Roman. I'm sharing my response on the IPPM-list, as we agreed.

in-line below, [acm]
Al

> -----Original Message-----
> From: Roman Danyliw <[e-mail]>
> Sent: Friday, October 21, 2022 8:34 PM
> To: MORTON JR., AL <[e-mail]>
> Cc: CIAVATTONE, LEN <[e-mail]>; Brian Weis <[e-mail]>; Tommy
> Pauly ([e-mail]) <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; Roman Danyliw <[e-mail]>
> Subject: RE: Seeking advice on encryption requirements for a new measurement
> protocol
> 
> Hi Al! Thanks for the continued pointers and sorry for the delay.
> 
> Hi Brian!  Thanks for the early SECDIR review.
[acm] Big +1 on that, the improvements in draft--03 are the result of exchanges with Brian!
> 
> Up front, this response is not coordinated with Paul.  I think the question is
> what are thoughts around "fully-encrypted operation during the control and
> measurement phases of a new IPPM standards Track Protocol."  Let me flip it
> around since I don't have all answers on what's acceptable given the expected
> deployment.  Help me out:
> 
> (1) What's the applicability scope of the protocol -- is it Internet and/or
> limited domain?  If it's limited domain, what assumptions can be made about
> who controls the network?
[acm] 
In the Scope for this (and previous related work, including the metric in RFC 9097), we say:

The primary application of the protocol described here is the same as in Section 2 of [RFC7497] where:
 + The access portion of the network is the focus of this problem statement. The user 
   typically subscribes to a service with bidirectional access partly described by rates 
   in bits per second.

I don't want to get tangled-up in the definition of Internet access here: it involves a single administrative domain as one might imagine. I think it would be consistent with the scope that users can make measurements of their private networks that connect to access (ideally they deploy their own server).

However, there's nothing in the draft to discourage users from deploying this protocol Internet-wide. In fact, the minimal RTT sensitivity of this capacity metric and method makes it a attractive alternative to other (TCP-based) methods.

> 
> (2) Per the question of confidentiality services, I think this is intended to
> support active measurement so there isn't any user activity data in the
> payload.  Is that right? If there is user data, encryption is definitely
> needed.
[acm] 
Exactly right. As with all Active measurements, the traffic emanates from the measurement process. Users don't have the opportunity to communicate SPI anywhere.  But see below:

> 
> (3) If an on-path observer sees this traffic, what will they see?
[acm] 
I'll break this down in the two phases, Control and Data. Data phase first because it contains the most interesting/valuable information.

Data phase:
In this phase, client and server take on the roles of sender or receiver, depending on the transmission direction (upstream or downstream test).

The sender transmits synthetic traffic (Load PDUS).
The receiver makes measurements on the traffic (and sends status feedback messages). 

A unique feature of this protocol is that status feedback messages are exchanged frequently between the client and server during a test.

If the receiver is the remote client, it sends the results of measurements during the recent status interval (~50ms) in each status feedback message.

If the receiver is the server, it considers the measurements it made and transmits the new  sending rate level that it wants the client to use.

BOTH the measurements and sending rate level in the status feedback would be interesting to an on-path observer (probably more so than any other information in the Control phase).

The communications to gracefully stop a test take place during the Data phase, and we have already considered an attack on this info (and mitigation) in draft--03.

Control phase:
In this phase, lots of mundane test configuration is exchanged (client requested & accepted/rejected by the server). 
The most interesting info is the optional ability for the client to indicate the maximum bit rate it intends to use during a test (so the server can perform test capacity management and reject a test if it has insufficient capacity). An on-path observer might correlate the client's bit rate request with their subscribed service rate.

> 
> -- if this is in a limited domain, the operator of the network could get
> visibility in all of the details of the test, regardless of if the operator
> ran them or they came from the user.    Are the network operators the same as
> the user that would run the test?
[acm] 
The main difference between an operator's test and a test between two users is likely the location of the server host.  An operator has the freedom to locate a server near the network end of the access pipe, while two users would likely be testing two access pipes in parallel (plus some networks that connect the access).
 
> ...  Is it acceptable for the network operator
> to see all of the details of any the measurement?
[acm] 
I think so, but I'm working at a network operator 😊
However, it is considered polite (if not a requirement in some service agreements) to notify the network operator when testing their network. The agreement might involve sharing the measurement results with the service operator.

> 
> -- if this is the Internet, anyone on the path can see all the details of the
> measurements using the protocol.  Roughly what's the exposure of someone doing
> passive measurement on this active measurement.
[acm] 
The results of measurements or the control of the sender's rate are the most interesting information exposed (see 3, Data phase, above).


> There is no nuance between
> the operator being tightly tied to the user to consider.  What does observing
> the test traffic reveal about the initiator or recipient end-points of the
> measurements? 
[acm] 
IP addresses, and the fact that measurements were conducted, at least.
IDK anything else, offhand.  

> Relationship between the two measurement points?  
[acm] 
The client's IP address (visible on the Internet) is likely the subscriber's globally routable IP address, assigned by the service provider and located at the edge of the access network. Can't make similar assumptions about the server's IP (could be anywhere).

> ...Could the
> provisioning or network configuration be revealed? 
[acm] 
Measurement results likely reveal the affects of traffic shapers on access. There is a lot of shaping deployed on access. Configuration aspects of other traffic management methods could also be revealed (to experts in the field).

>   Could the very existence
> of there being measurement traffic be a problem?
[acm] 
If too many users try to test high-speed traffic at the same time, there could be network overload and adverse affects on non-testing users. That's always a risk with the capacity measurements that users can download and use today (something goes wrong, everybody starts testing...).

> 
> On the balance, I'm suspecting that as long as everything in the data channel
> is synthetic, it's probably ok to not be encrypted. 
[acm] 
That was true for OWAMP, TWAMP, and STAMP, the earlier IPPM Active measurement protocols (but we had an encrypted mode anyway - AFAIK it was never implemented in the widely deployed TWAMP).
Unfortunately for this point, the measurements or sender rate control messages are in the data channel in this protocol.

> Per the control channel,
> I think I'd have to look more carefully.  If the former was in the clear and
> the latter encrypted, I don't have a sense for whether passive observation of
> the data channel could reconstruct certain information about from the control
> channel.  I think the answers to the above might steer the design choice.
[acm] 
Some high-level Control phase configurations could be reconstructed by observing the Data phase, such as test duration, status feedback interval, and actual sending rates. But these might be determined even if the traffic in the Data Phase was encrypted.

> 
> Does that help with some of the deliberations you are having?  Should we talk
> more?
[acm] 
It does, and thanks for your structured questions.

I suspect we might next need to look into the simplest solutions to provide privacy through encryption, but see what you think.

Al

> 
> Roman
> 
> > -----Original Message-----
> > From: MORTON JR., AL <[e-mail]>
> > Sent: Sunday, October 2, 2022 2:57 PM
> > To: Roman Danyliw <[e-mail]>; [e-mail];
> > [e-mail]
> > Cc: CIAVATTONE, LEN <[e-mail]>; Brian Weis <[e-mail]>;
> > Tommy Pauly ([e-mail]) <[e-mail]>;
> > [e-mail]
> > Subject: RE: Seeking advice on encryption requirements for a new
> > measurement protocol
> >
> > Hi Roman and Paul,
> >
> > This is a reminder that we asked for your advice regarding an IETF
> requirement
> > for fully-encrypted operation during the control and measurement phases of a
> > new IPPM standards Track Protocol. See below.
> >
> > We have just uploaded
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> ietf-ippm-capacity-protocol-
> 03__;!!BhdT!gNVOdtiLeJX2bP0TWUIz4ZlWrqJYDYvV7f7U3FDH_AmZ8gLjqLGaT6Jod7amsRAUxK
> ITPw$
> >
> > which effectively addresses all of Brian Weis' Early SEC-DIR review
> comments,
> > so now the question to you on whether we need fully-encrypted operation is
> > top-of-mind.
> >
> > Thanks for your consideration and regards, Al and Len
> >
> > > -----Original Message-----
> > > From: MORTON JR., AL
> > > Sent: Thursday, September 8, 2022 5:12 PM
> > > To: [e-mail]; [e-mail]; [e-mail]
> > > Cc: CIAVATTONE, LEN <[e-mail]>; Brian Weis
> > <[e-mail]>;
> > > Tommy Pauly ([e-mail]) <[e-mail]>;
> > > [e-mail]
> > > Subject: Seeking advice on encryption requirements for a new
> > > measurement protocol
> > >
> > > Hi Roman and Paul,
> > >
> > > The IPPM WG is developing a new active measurement protocol, and we
> > > would like to receive your advice. The protocol currently has no
> > > option for fully- encrypted operation during the control and
> > > measurement phases. We'll discuss the protocol details and
> > > accuracy/security trade-offs below. Our AD (Martin
> > > Duke) suggested that starting a dialog on this topic now would be most
> > > efficient for specification development (and the running code).
> > >
> > > Background:
> > > The UDP-based protocol has two phases of operation: a Control phase
> > > where testing options are agreed between the remote client and the
> > > server hosts, and a Data phase where one of the hosts sends Load
> > > packets fast enough to measure the path capacity at the IP-Layer, and
> > > the receiving host measures the packet stream. Frequent Feedback
> > > messages are exchanged while the test is in- progress, and they are also
> used
> > for round-trip measurements.
> > >
> > > We have received many helpful and enlightening comments from Brian
> > > Weis in his Early SEC-DIR review, mostly pertaining to Key management,
> > > Firewall configuration, and Authenticated operation modes. You may
> > > have seen several of our messages exchanged on the SEC-DIR list. But
> > > we all still wonder if there is a requirement for full encryption in
> > > IETF protocols.  We don't want to guess whether the absence of some
> > > features, like full encryption or authentication of *all* message
> > > types, are deal-breakers for approval of a protocol where the
> > > clear-text packet generation and measurement is often  near the limit of
> > remote client or server processing power (or both).
> > >
> > > A concrete example of the measurement accuracy trade-off with security
> > > features is when the maximum packet processing rate of the secure
> > > tunnel GWs (encap, decap, or both) is less than the Maximum IP-Layer
> > > Capacity of the path. In this case, every measurement result would be in
> > error.
> > >
> > > We have discussed using DTLS for the Control phase of the protocol,
> > > where retransmission and ordered delivery would be seen as additional
> > features.
> > > However, these same features disqualify DTLS from the Data phase,
> > > where it is essential to measure packet loss when it occurs (along
> > > with re-ordering, etc.).
> > >
> > > URLS for the current draft [0] and Discussion at IETF-114 [1] (starts
> > > about 30 minutes in).
> > > The -03 version of the draft is coming, where we mostly implement
> > > Brian's take on required and optional authenticated modes.
> > >
> > > Thanks for your consideration and regards, Al and Len
> > >
> > >
> > > [0]
> > > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-
> ippm-capacity-protocol-
> 02.h__;!!BhdT!gNVOdtiLeJX2bP0TWUIz4ZlWrqJYDYvV7f7U3FDH_AmZ8gLjqLGaT6Jod7amsRBW
> f-YNgA$
> > > tml
> > >
> > > [1] https://urldefense.com/v3/__https://www.youtube.com/watch?v=wRhzhBrH-
> KY__;!!BhdT!gNVOdtiLeJX2bP0TWUIz4ZlWrqJYDYvV7f7U3FDH_AmZ8gLjqLGaT6Jod7amsRC7-
> A1oXA$