Subject: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14

From: Tom Herbert <[email-masked]>
Date: Fri, 3 Apr 2020 09:48:42 -0700

Hi, a few comments.

I don't understand this statement from the draft:

"The value of this information would be enhanced if the exposed
information could be verified to match the internal state of the
transport by observing the transport behaviour."

I assume this means that the network nodes would need to understand
the internal state of transport protocols. How would this work?

If the idea is that the exposed information is somehow verified with
the endpoints that securely provide the information then maybe I
understand that. But, if the idea is that intermediate nodes need to
autonomously deduce the internal state themselves, I think that is
problematic. Aside from all the known problems that stateful network
devices have caused, there seems to be a circular dependency here.
AFAIK the only way to deduce the internal state of a transport
connection in the network would be by inspecting the exposed transport
information, but this statement seems to be saying the exposed
information can't be trusted unless the internal state has been
deduced. Am I missing something?

>From the draft:

"An endpoint/protocol could choose to expose transport header
information to optimise the benefit it gets from the network
[RFC8558]."

There is also the possibility that the endpoints didn't expose
transport layer information, but the network incorrectly thinks it
did. The network may simply misinterpret bits in packets as being
transport layer information when in fact the data can be something
completely different and unrelated. The canonical example of this is
QUIC or any transport encapsulated in UDP payload. Per, RFC7605,
transport port numbers only have meaning at end points. So for example
a network device may think a packet with UDP destination port 80 is
QUIC, when in fact it is something completely different, hence the
network device may misinterpret the payload as being QUIC. I suspect
it's unlikely that this situation will benefit the user, and more
likely the network would not treat such packets well. There's been
some work on this problem, like magic numbers in SPUD or analysis to
mitigate the effects of misinterpretation like done for QUIC spin bit,
but I don't believe anyone has proposed a general solution (other than
moving the necessary information into the network layer and have
intermediate nodes stop doing DPI).  I believe this problem should be
mentioned in the draft with a reference to RFC7605 .

Tom

---

From: "Black, David" <[email-masked]>
Date: Fri, 3 Apr 2020 20:06:07 +0000

Hi Tom,
[writing as draft shepherd]

[1]
> the internal state of transport protocols. How would this work?

Oops, that's not a good assumption - in 20/20 hindsight, the quoted
text should focus on protocol behavior rather than internal state.

Suggested revised text:

   The usefulness of this information would be enhanced if the exposed
   information could be verified to match the protocol's actual behavior,
   e.g., by observing whether the network traffic sent by the protocol
   is consistent with the exposed information in that traffic.

Beyond that, one could (partially) infer protocol state from observed
traffic behavior, but I don't think it's important to say that.

[2]
> QUIC or any transport encapsulated in UDP payload.

That's actually an observation about transport-layer vs. network-layer
information exposure that would be better addressed slightly earlier in
the draft where both of those layers are discussed.

After the first paragraph in Section 6.1 (Exposing Transport Information
in Extension Headers) looks like a good place to make that observation.

After this paragraph:

   At the network-layer, packets can carry optional headers (similar to
   Section 5) that may be used to explicitly expose transport header
   information to the on-path devices operating at the network layer
   (Section 3.1.3).  For example, an endpoint that sends an IPv6 Hop-by-
   Hop option [RFC8200] can provide explicit transport layer information
   that can be observed and used by network devices on the path.

Add this paragraph:

   Network-layer optional headers explicitly indicate the information
   that is exposed, whereas more effort may be required for a network
   device to determine whether a packet contains a partially encrypted
   transport header.  A particular concern is UDP-encapsulated protocols
   because the UDP ports do not definitively indicate which protocol has
   been encapsulated, even though some protocols are the predominant
   usage of specific UDP destination ports (e.g., a packet sent to UDP
   port 4500 is highly likely to contain UDP-encapsulated IKE [RFC3948]
   or IKEv2 [RFC7296]).
   
Would that work?

Thanks, --David

> -----Original Message-----
> From: tsvwg <[email-masked]> On Behalf Of Tom Herbert
> Sent: Friday, April 3, 2020 12:49 PM
> To: tsvwg
> Subject: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi, a few comments.
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 3 Apr 2020 17:03:54 -0700

>    is consistent with the exposed information in that traffic.
But then that would be akin to making inferences encrypted data, and
preventing such inferences in the network is precisely one of the
reasons the transport header is being encrypted by the end hosts.

>    port 4500 is highly likely to contain UDP-encapsulated IKE [RFC3948]
That's good, but I think there should be a reference to RFC7605 also.

Tom

---

From: "Black, David" <[email-masked]>
Date: Sat, 4 Apr 2020 00:35:54 +0000

Tom,

Ok, 1 issue settled, 1 more to go ...

[1]
> reasons the transport header is being encrypted by the end hosts.

I think that response is overdone for several reasons:

1.  A decision to expose some transport header information is a decision to allow this sort of inference from observations (sorry, there's no free lunch available here).

2.  What is being inferred is protocol functional behavior, not the specific contents of the encrypted headers that the protocol is using as part of producing that behavior, so characterizing this as somehow reversing part of the encryption is a stretch.

3.  Beyond that, if one is determined to prevent all inference of protocol functional behavior, not exposing any transport protocol information does not suffice to frustrate all traffic analysis (e.g., set a few CE marks on packets inbound to a protocol receiver that supports ECN, sit back and watch what happens).  There's been extensive security work on traffic analysis countermeasures which is (IMHO) not germane to this draft.

[2] 
> That's good, but I think there should be a reference to RFC7605 also.

Ok, I think the factual statement suffices, but I won't object to a reference to RFC7605.

Thanks, --David

> From: Tom Herbert <[email-masked]>
> Sent: Friday, April 3, 2020 8:04 PM
> To: Black, David
> Cc: tsvwg
> Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
> 
> 
> [EXTERNAL EMAIL]
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 4 Apr 2020 08:13:15 +0100

See below on (2).

> Ok, I think the factual statement suffices, but I won't object to a reference to RFC7605.

The phrase "whereas more effort may be required" is speculation. It 
could be that hardware in routers, etc has been designed and optimised 
for network-header extensions to allow metrics to be extracted, or it 
could be that it hasn't, or that this is only true from some vendors or 
some models of equipment. It's possible to say that about many things. I 
don't think we should speculate here, unless we can point to references 
that have observed this.

I think we already have covered the ground for the second part of the 
additonal text.The current text on ports is:

    In some uses, a low-numbered (well-known) transport port number can
    identify the protocol.  However, port information alone is not
    sufficient to guarantee identification.  Applications can use
    arbitrary ports, multiple sessions can be multiplexed on a single
    port, and ports can be re-used by subsequent sessions.  UDP-based
    protocols often do not use well-known port numbers.  Some flows can
    be identified by observing signalling protocol data (e.g., [RFC3261],
    [I-D.ietf-rtcweb-overview]) or through the use of magic numbers
    placed in the first byte(s) of the datagram payload [RFC7983].

I do agree with Tom that this could benefit from the addition of a reference to RFC7605!

I do not personally buy this: "A particular concern is UDP-encapsulated protocols".
To me, this has little to do with encryption, but we could say something more here
if there is a need to say more. This seems true of other protocols. They can
be layered also, we see many services over HTTP/TCP and people shouldn't
disect traffic based only on a TCP port.

---

From: "Black, David" <[email-masked]>
Date: Sun, 5 Apr 2020 22:32:34 +0000

The text on ports is in Section 3.1.1 of the draft - it makes a lot of sense to refer to it rather than cover the same territory again, so mea culpa for overlooking that text.  Also, in 20/20 hindsight, “more effort” was not the right word choice to convey “more involved” or “more complex” – besides, it’s better to simply point out that the transport protocol has to be identified in order to use its headers.

Trying again on the new paragraph, much of it can be replaced by just citing

   that is exposed, whereas use of exposed transport header information

   requires identifying the transport protocol. See Section 3.1.1

   for further discussion of transport protocol identification.

That’s shorter, crisper text that shifts the discussion to Section 3.1.1, where a reference to RFC 7605 makes a lot of sense to me, along with a minor edit to this paragraph:

OLD

   UDP-based protocols often do not use well-known port numbers.
NEW

   UDP-based protocols often do not use well-known port numbers,

   and use of a well-known port number is not limited to the

   protocol for which the port is well known [RFC7605].

This approach looks significantly better than what I originally wrote.

Thanks, --David (still as draft shepherd)

From: Gorry Fairhurst <[email-masked]>
Sent: Saturday, April 4, 2020 3:13 AM
To: Black, David; Tom Herbert
Cc: tsvwg
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14

[EXTERNAL EMAIL]

See below on (2).

Tom,

[1]

Suggested revised text:

[2]

Add this paragraph:

   or IKEv2 [RFC7296]).

Would that work?

Thanks, --David

The phrase "whereas more effort may be required" is speculation. It could be that hardware in routers, etc has been designed and optimised for network-header extensions to allow metrics to be extracted, or it could be that it hasn't, or that this is only true from some vendors or some models of equipment. It's possible to say that about many things. I don't think we should speculate here, unless we can point to references that have observed this.

I think we already have covered the ground for the second part of the additonal text.The current text on ports is:

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

From: Tom Herbert <[email-masked]><mailto:[email-masked]>

To: Black, David

Cc: tsvwg

[EXTERNAL EMAIL]

On Fri, Apr 3, 2020 at 1:06 PM Black, David <[email-masked]><mailto:[email-masked]> wrote:

Hi Tom,

[1]

Suggested revised text:

[2]

[RFC8558]."

After this paragraph:

Add this paragraph:

   or IKEv2 [RFC7296]).

Would that work?

Tom

Thanks, --David

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

From: tsvwg <[email-masked]><mailto:[email-masked]> On Behalf Of Tom Herbert

To: tsvwg

[EXTERNAL EMAIL]

Hi, a few comments.

[RFC8558]."

Tom

---

From: Joseph Touch <[email-masked]>
Date: Sun, 5 Apr 2020 15:50:46 -0700

> On Apr 5, 2020, at 3:32 PM, Black, David <[email-masked]> wrote:
> 
> ...

RFC7605 doesn’t say this, or at least most of this.

Yes, there’s no rule that well-known port numbers are used. But that’s not either unique to nor biased towards UDP vs TCP.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 6 Apr 2020 11:23:25 +0100

On 05/04/2020 23:50, Joseph Touch wrote:
>
>
>> On Apr 5, 2020, at 3:32 PM, Black, David <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> The text on ports is in Section 3.1.1 of the draft - it makes a lot 
>> of sense to refer to it rather than cover the same territory again, 
>> so mea culpa for overlooking that text.  Also, in 20/20 hindsight, 
>> “more effort” was not the right word choice to convey “more involved” 
>> or “more complex” – besides, it’s better to simply point out that the 
>> transport protocol has to be identified in order to use its headers.
>> ...
>> OLD
> Yes, there’s no rule that well-known port numbers are used. But that’s 
> not either unique to nor biased towards UDP vs TCP.
>
> Joe

I understand, I think we can mention RFC7605 in 3.1.1 by adding this to 
the para about ports to read something like:

"In some uses, an assigned transport port (e.g., low-numbered port) can 
identify the protocol [RFC7605]. However, port information alone is not 
sufficient to guarantee identification. Applications can use arbitrary 
ports and do not need to use well-known port numbers. The use of a 
well-known port number is also not limited to the protocol for which the 
port is well known. "

Gorry

---

From: Joseph Touch <[email-masked]>
Date: Mon, 6 Apr 2020 08:00:00 -0700

Notes below...

> On Apr 6, 2020, at 3:23 AM, Gorry Fairhurst <[email-masked]> wrote:
>>> On Apr 5, 2020, at 3:32 PM, Black, David <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> ...
>>> ...
>>> OLD
> I understand, I think we can mention RFC7605 in 3.1.1 by adding this to the para about ports to read something like:
> 
> "In some uses, an assigned transport port (e.g., low-numbered port)
> 
(e.g., 0..49151)

[I would avoid the term ‘low-numbered’, which could be interpreted as meaning 0–1023]

>  identify the protocol [RFC7605]. However, port information alone is not sufficient to guarantee identification. Applications can use arbitrary ports and do not need to use well-known port numbers. The use of a well-known port number is also not limited to the protocol for which the port is well known. 
> 
Well-known often implies System.

As per RF7605, I’d encourage the use of “assigned” for the entire range from 0..49151.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 6 Apr 2020 17:25:41 +0100

On 06/04/2020 16:00, Joseph Touch wrote:
> Notes below...
>
>> On Apr 6, 2020, at 3:23 AM, Gorry Fairhurst <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>> Yes, there’s no rule that well-known port numbers are used. But 
>>> that’s not either unique to nor biased towards UDP vs TCP.
>>>
>>> Joe
>>
>> I understand, I think we can mention RFC7605 in 3.1.1 by adding this 
>> to the para about ports to read something like:
>>
>>  identify the protocol [RFC7605]. However, port information alone is 
>> not sufficient to guarantee identification. Applications can use 
>> arbitrary ports and do not need to use well-known port numbers. The 
>> use of a well-known port number is also not limited to the protocol 
>> for which the port is well known.
>>
OK. We now have:

In some uses, an assigned transport port (e.g., 0..49151) can
identify the protocol [RFC7605]. However, port information

alone is not sufficient to guarantee identification....

Gorry

---

From: Joseph Touch <[email-masked]>
Date: Mon, 6 Apr 2020 18:42:31 -0700

Hi, Gorry,

I’d suggest as follows (just to follow through on the changes):

In some uses, an assigned transport port (e.g., 0..49151) can identify the protocol [RFC7605]. However, port information alone is not sufficient to guarantee identification. Applications can use arbitrary ports and do not need to use assigned port numbers. The use of an assigned port number is also not limited to the protocol for which the port is intended.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 7 Apr 2020 07:51:43 +0100

On 07/04/2020 02:42, Joseph Touch wrote:
>     In some uses, an assigned transport port (e.g., 0..49151)
>     can identify the protocol [RFC7605]. However, port
>     information alone is not sufficient to guarantee identification.
>     Applications can use arbitrary ports and do not need to use
>     assigned port numbers. The use of an assigned port number is also
>     not limited to the protocol for which the port is intended.
>
>
> Joe

That also works for me, thank you for this replacement text, we have 
used this for rev -15.

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 Apr 2020 07:40:14 -0700

> In some uses, an assigned transport port (e.g., 0..49151) can identify the protocol [RFC7605]. However, port information alone is not sufficient to guarantee identification. Applications can use ar…

Joe,

RFC7605 acknowledges that port numbers are used to identify the
application protocol, but clearly doesn't condone the practice. I
suggest the text should just paraphrase RFC7605:

"Port numbers are sometimes used by intermediate devices on a network
path to interpret transport protocol payload, however any
interpretation of port numbers -- except at the endpoints -- may be
incorrect, because port numbers are
meaningful only at the endpoints [RFC7605]."

Tom

---

From: Joseph Touch <[email-masked]>
Date: Tue, 7 Apr 2020 08:11:54 -0700

Hi, Tom,

> On Apr 7, 2020, at 7:40 AM, Tom Herbert <[email-masked]> wrote:
> 
> suggest the text should just paraphrase RFC7605:’

I don’t quite understand the above, esp. the use of “condone”. Port numbers are assigned *exactly* for endpoints to identify application protocols *in the absence of any other more explicit coordination* (the draft doesn’t say it so directly, but that’s the summary). 

That said, I was OK with the resolved text I had suggested, with or without the text below - which is also fine.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 Apr 2020 08:34:35 -0700

Joe,

I meant by using port numbers at intermediate nodes for identifying
application protocols. For example, QUIC is assigned UDP port number
80 and the spinbit was created to be visible and processed by
intermediate nodes. The only generic way intermediate nodes can
identify QUIC is by matching the assigned UDP port number. RFC7605
says that such matching may not be correct, so consideration needs to
be taken what happens if things are misinterpreted (IIRC, processing
of spinbit for a packet misinterpreted as being QUIC is considered
innocuous).

Also, a corollary should be the hard requirement: "Intermediate nodes
MUST NOT ever modify transport payload". I don't believe this draft
mentions the fact that some intermediate nodes modify unencrypted
transport layer headers in flight, but this does happen. For instance,
there are devices that will modify the TCP receive window to optimize
traffic flow (I believe there are some routers for satellite links
that do this). If this technique were applied to QUIC where the
network modified some "exposed" fields in the QUIC header then this
would risk systematic data corruption for UDP packets misinterpreted
as QUIC (putting the transport layer in a modifiable HBH option would
not have this problem).

Tom

---

From: Joseph Touch <[email-masked]>
Date: Tue, 7 Apr 2020 08:42:59 -0700

> On Apr 7, 2020, at 8:34 AM, Tom Herbert <[email-masked]> wrote:
> 
> On Tue, Apr 7, 2020 at 8:12 AM Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi, Tom,
>> 
> application protocols.

Oh, sorry. I didn’t get that from the text, but agreed.

> For example, QUIC is assigned UDP port number

Agreed.

> MUST NOT ever modify transport payload”.

As a general principle, yes - agreed. There’s always the caveat that it’s always OK *with the consent of the endpoints*, e.g., if an enterprise wants to set up the network that way for their users. But in the arbitrary “middle” of the network, it *should* IMO always be MUST NOT.

> I don't believe this draft
> that do this).

Yes, and they then complain that mechanisms like IPsec “interfere” with that “feature”. Some of what they do might be relatively innocuous, but some - esp. forging ACKs to reduce endpoint-perceived RTT - runs a significant risk of undermining TCP semantics of reliable delivery.

> If this technique were applied to QUIC where the

---

From: "Black, David" <[email-masked]>
Date: Tue, 7 Apr 2020 16:20:33 +0000

>> Also, a corollary should be the hard requirement:
>> "Intermediate nodes MUST NOT ever modify transport payload”.

> As a general principle, yes - agreed. There’s always the caveat that it’s always OK
> *with the consent of the endpoints*, e.g., if an enterprise wants to set up the
> network that way for their users. But in the arbitrary “middle” of the network, it
> *should* IMO always be MUST NOT.

As a general requirement, that’s fine, but it should be stated somewhere other than in this draft, e.g., as this draft is intended to become an Informational RFC.

Thanks, --David (as draft shepherd)

From: tsvwg <[email-masked]> On Behalf Of Joseph Touch
Sent: Tuesday, April 7, 2020 11:43 AM
To: Tom Herbert
Cc: Gorry Fairhurst; tsvwg
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14

[EXTERNAL EMAIL]

On Apr 7, 2020, at 8:34 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Apr 7, 2020 at 8:12 AM Joseph Touch <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Tom,

On Apr 7, 2020, at 7:40 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Apr 6, 2020 at 6:42 PM Joseph Touch <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Gorry,

Joe,

Agreed.

Tom

Joe

Tom

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 Apr 2020 11:11:33 -0700

> As a general requirement, that’s fine, but it should be stated somewhere other than in this draft, e.g., as this draft is intended to become an Informational RFC.
David,

Changing transport layer header, e.g. for traffic flow optimization
such as those devices doing receive window modulation, might also be
another use of transport header information that could be included in
section 2.1. Currently, the draft only seems to consider uses based on
passive observation of transport headers.

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 7 Apr 2020 20:09:43 +0100

> passive observation of transport headers.

Yes, that was the intention to talk about using the information, not 
changing the header.  WE don't discuss methods that modify the transport 
header, some ACK-modification methods, Window Modulation, 
proxy-intercept, PEPs, etc, which can't work if you authenticate the 
headers. We therefore were didn't see the need to call-out methods that 
require changes to the transport header. There are other docs that take 
a  look at a much broader swathe of mechanisms. If you want to read more 
about those, see RFC 8404.

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 Apr 2020 12:35:35 -0700

> about those, see RFC 8404.

Gorry,

I think it's apropos discussion to this draft, especially if the
recommendation is for protocol designers to selectively choose which
fields to make visible, whereby making something "visible" to the
network might not only mean that intermediate devices can read the
data, but they may write it as well.

Tom

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 7 Apr 2020 17:53:49 -0500

I'm happy to defer to Magnus on this, but ...

On Tue, Apr 7, 2020 at 2:10 PM Gorry Fairhurst <[email-masked]> wrote:

> >> As a general requirement, that’s fine, but it should be stated
> somewhere other than in this draft, e.g., as this draft is intended to
> become an Informational RFC.
> >>
> > David,
> >
> headers.

That was my understanding when I was encouraging Gorry on this draft.

In addition to the likelihood that the description of passive observers
would be considerably delayed by inclusion of description of active
middleboxen dorking with transport headers (we did not lack for controversy
on passive observers, in 2017), I wasn't confident that we could come up
with a taxonomy of what dorkers were doing, and why they were doing it.

That's probably the result of me spending time in the SIP community, when
we tried to describe what Session Border Controllers were doing in
https://tools.ietf.org/html/rfc5853, while SBC vendors were adding features
as quickly as their engineers could type. You won't be shocked to discover
that vendors considered their dorking to be "secret sauce", that
differentiated their products from their competitors, and were not lining
up to tell us what they were doing.

So, unless someone can convince the working group that documenting the
dorkers can be completed in finite time and space, I'd discourage expanding
the scope of this draft, at this time.

And that's not in any way intended to say that documenting the dorkers
would be a bad thing, if the working group thought it was possible.

Best,

Spencer

> We therefore were didn't see the need to call-out methods that

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 Apr 2020 16:29:32 -0700

On Tue, Apr 7, 2020 at 3:54 PM Spencer Dawkins at IETF
<[email-masked]> wrote:
> In addition to the likelihood that the description of passive observers would be considerably delayed by inclusion of description of active middleboxen dorking with transport headers (we did not lack for controversy on passive observers, in 2017), I wasn't confident that we could come up with a taxonomy of what dorkers were doing, and why they were doing it.
>
> That's probably the result of me spending time in the SIP community, when we tried to describe what Session Border Controllers were doing in https://tools.ietf.org/html/rfc5853, while SBC vendors were adding features as quickly as their engineers could type. You won't be shocked to discover that vendors considered their dorking to be "secret sauce", that differentiated their products from their competitors, and were not lining up to tell us what they were doing.
>

Spencer,

That reminds me of the olden days when some dorker providers were
parsing HTTP and replacing ads with their own :-)

> So, unless someone can convince the working group that documenting the dorkers can be completed in finite time and space, I'd discourage expanding the scope of this draft, at this time.
>

it might be good to clarify the draft that only uses cases of
transport information being observed are in scope.

As I said, the potential tussle happens if the transport protocol
designer decides to make some transport header information visible and
doesn't consider that the network may then modify the information-- I
believe this is prevented in QUIC since the plaintext parts of the
QUIC header are authenticated, but that might not be the case for
other transport protocols.

Tom

> And that's not in any way intended to say that documenting the dorkers would be a bad thing, if the working group thought it was possible.
>
> Best,
>
> Spencer
>
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 7 Apr 2020 20:57:11 -0500

Hi, Tom,

On Tue, Apr 7, 2020 at 6:29 PM Tom Herbert <[email-masked]> wrote:

> > That's probably the result of me spending time in the SIP community,
> when we tried to describe what Session Border Controllers were doing in
> https://tools.ietf.org/html/rfc5853, while SBC vendors were adding
> features as quickly as their engineers could type. You won't be shocked to
> discover that vendors considered their dorking to be "secret sauce", that

I'm guiltier than I look about dorking with TCP and HTTP in middleboxes,
but let's just walk away from that  ...

> transport information being observed are in scope.

That would indeed be a clarification - I'll let the shepherd and author Do
The Right Thing, of course :-)

Best,

Spencer

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 8 Apr 2020 11:08:23 +0100

On 08/04/2020 02:57, Spencer Dawkins at IETF wrote:
> Hi, Tom,
>
> On Tue, Apr 7, 2020 at 6:29 PM Tom Herbert <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > On Tue, Apr 7, 2020 at 2:10 PM Gorry Fairhurst
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >>
>     >> > On Tue, Apr 7, 2020 at 9:20 AM Black, David
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >> >> As a general requirement, that’s fine, but it should be
>     stated somewhere other than in this draft, e.g., as this draft is
>     intended to become an Informational RFC.
>     >> >>
>     >> > David,
>     >> >
>     > In addition to the likelihood that the description of passive
>     observers would be considerably delayed by inclusion of
>     description of active middleboxen dorking with transport headers
>     (we did not lack for controversy on passive observers, in 2017), I
>     wasn't confident that we could come up with a taxonomy of what
>     dorkers were doing, and why they were doing it.
>     >
>     > That's probably the result of me spending time in the SIP
>     community, when we tried to describe what Session Border
>     Controllers were doing in https://tools.ietf.org/html/rfc5853,
>     while SBC vendors were adding features as quickly as their
>     engineers could type. You won't be shocked to discover that
>     vendors considered their dorking to be "secret sauce", that
>     differentiated their products from their competitors, and were not
>     lining up to tell us what they were doing.
>     >
>
>     Spencer,
>
> I'm guiltier than I look about dorking with TCP and HTTP in 
> middleboxes, but let's just walk away from that  ...
>
>
>     > So, unless someone can convince the working group that
>     documenting the dorkers can be completed in finite time and space,
>     I'd discourage expanding the scope of this draft, at this time.
>     >
>
> That would indeed be a clarification - I'll let the shepherd and 
> author Do The Right Thing, of course :-)
>
> Best,
>
> Spencer
>
>
>     > And that's not in any way intended to say that documenting the
>     dorkers would be a bad thing, if the working group thought it was
>     possible.
>     >
>     > Best,
>     >
>     > Spencer
>
I see more now. Thanks Tom for raising this threda up, I will take a 
look at the document - I see that since we added examples in the first 
WGLC, there are some places where the language could mislead. I'll seek 
to repair those in the next rev.

Gorry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 8 Apr 2020 07:57:34 -0500

On Wed, Apr 8, 2020, 05:08 Gorry Fairhurst <[email-masked]> wrote:

> I also see more now - I'm happy to defer to MARTIN on this!

My apologies for missing the change in responsible ADs.

Best,

Spencer

> I see more now. Thanks Tom for raising this threda up, I will take a look
> at the document - I see that since we added examples in the first WGLC,
> there are some places where the language could mislead. I'll seek to repair
> those in the next rev.
>
> Gorry
>