Subject: Re: [tcpinc] TCP's treatment of data in SYN packets

From: "David Mazieres" <[email-masked]>
Date: Mon, 01 Aug 2016 00:36:54 -0700

Oops, I failed to notice that you had in-line comments as well.  Please
read this instead of the previous version.

Sorry,
David

4.7.  Data in SYN segments

   TEPs MAY specify the use of data in SYN segments so as to reduce the
   number of round trips required for connection setup.  The meaning of
   data in a SYN segment with an ENO option (a SYN+ENO segment) is
   determined by the last TEP identifier in the ENO option, which we
   term the segment's _SYN TEP_.

   A SYN+ENO segment MUST NOT include data unless the SYN TEP's
   specification defines the use of such data.  Furthermore, a SYN+ENO
   option MUST NOT include a non-empty TCP Fast Open (TFO) option
   [RFC7413].

   A host implementing ENO, even if ENO has been disabled by
   configuration, MUST discard the data in a received SYN+ENO segment if
   any of the following applies:

   o  Encryption is disabled for the connection,

   o  The received segment's SYN TEP is not the negotiated TEP,

   o  The negotiated TEP does not define the use of SYN data, or

   o  The SYN segment contains a non-empty TFO option or any other TCP
      option implying a conflicting definition of SYN data.

   A host MUST NOT acknowledge the sequence number of any discarded SYN
   data, but rather MUST acknowledge the other host's initial sequence
   number as if the received SYN segment contained no data.
   Furthermore, a host MUST NOT assume discarded SYN data will be
   identically retransmitted.  If later non-SYN segments contain
   different data for the same sequence numbers as SYN data, the host
   MUST process only data from non-SYN segments.

   If a host receives acknowledgment for data in a SYN+ENO segment but
   the SYN TEP governing that data is not the negotiated TEP (either
   because a different TEP was negotiated, or because encryption is
   disabled), then the host that sent the SYN+ENO segment MUST reset the
   TCP connection.  Proceeding in any other fashion risks misinterpreted
   SYN data.

   If a host sends data in a SYN-only SYN+ENO segment and subsequently
   receives a SYN-ACK segment without an ENO option, the host SHOULD
   reset the connection even if the SYN-ACK segment does not acknowledge
   the SYN data.  The reason is that a host sending a SYN-ACK segment
   without an ENO option does not necessarily follow the requirements of
   this section, and in particular could buffer SYN data and later
   process it instead of the contents of non-SYN segments with the same
   sequence numbers.  Barring empirical evidence against the existence
   of such buffering, it is not safe to assume unacknowledged SYN data
   has been discarded.

   To avoid unexpected connection resets, TEPs SHOULD support a normal
   mode of operation that does not make use of data in SYN-only
   segments.  Moreover, implementations SHOULD enable data in SYN-only
   segments only if explicitly requested by the application or in cases
   where such use is unlikely to cause connection failure.
   Implementations MAY provide a per-connection mandatory encryption
   mode that automatically resets a connection if ENO fails.  For TEPs
   that support it, an implementation MAY default to using SYN data when
   in mandatory encryption mode.

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 1 Aug 2016 12:20:44 +0100

> 4.7.  Data in SYN segments
[...]
>    any of the following applies:
[...]
>    MUST process only data from non-SYN segments.

Nit: the last two sentences could be read as specifying behaviour
for discarded SYN data even for either non-SYN+ENO segments or
for non-ENO-implementing hosts.  I don't think those should be
covered.

Otherwise, I think I'm happy.
-- 
Jeremy

---

From: Joe Touch <[email-masked]>
Date: Mon, 1 Aug 2016 08:53:26 -0700

>    o  Encryption is disabled for the connection,

You should be specific that this applies only to TEP-indicated
encryption. There are other encryptions that do not involve ENO (e.g.,
TCP-AO-ENC).

>       option implying a conflicting definition of SYN data.
Again, this needs to be specific to TEP-protected associations. I doubt
you want to (or should) disable TFO just for all connections at an
ENO-capable endpoint even when ENO isn't intended for a give connection.

>    A host MUST NOT acknowledge the sequence number of any discarded SYN
Again, "TEP-protected host"...

>    Furthermore, a host MUST NOT assume discarded SYN data will be
that host (or again "TEP-protected host")
>    different data for the same sequence numbers as SYN data, the host
again "that host" or "TEP-protected host"

>    If a host receives acknowledgment for data in a SYN+ENO segment but
again "that host" or "TEP-protected host"
>    disabled), then the host that sent the SYN+ENO segment MUST reset the
again "that host" or "TEP-protected host"
>    If a host sends data in a SYN-only SYN+ENO segment and subsequently
again "that host" or "TEP-protected host"
>    receives a SYN-ACK segment without an ENO option, the host SHOULD
again "that host" or "TEP-protected host", but would say MUST here
because...
>    of such buffering, it is not safe to assume unacknowledged SYN data
The issue is that the data may have been cached but not ACKd, and the
later resend of the changed SYN data might not overwrite the cached
data, because TCP does not guarantee that overlapping segment data will
overwrite old data. It might be useful to clarify that.
>    segments only if explicitly requested by the application
This seems odd to me - IMO, you should refer to an API command that
might result in SYN data, not to the application directly controlling
this protocol event.

That command might be "eager start" or something...

>  or in cases
at the expense of connection failure to endpoints whose TEP capabilities
have changed. I.e., you now have a brittle TCP, and you should state that.

Joe

---

From: Gavin McCullagh <[email-masked]>
Date: Mon, 1 Aug 2016 20:52:43 -0700

Just to satisfy my curiosity, how did this work (or did it?) with TCP SYN
Cookies?

I can imagine a tcp listener which was implementing SYN Cookies only ACKing
the initial SYN sequence number and not the data which it discarded, then
the application retransmitting that data either on the subsequent ACK or
the next data packet.  Does that generally just work with most/all tcp
implementations on the other side?  I suppose it ought to?

Gavin

On Wed, Jul 27, 2016 at 11:37 PM, Derek Fawcus <
[email-masked]> wrote:

> On Thu, Jul 28, 2016 at 12:24:19am +0100, Derek Fawcus wrote:
> >
> > Implying that a passive opener which chose to ack such data bytes would
> > have to buffer such data until the handshake completes;  but I'm not
> > aware of any stack which actually works that way.
>
> Except the old KA9Q NOS,  which was tickling my memory...
>
> It did have the ability to send such SYN data.
>
> DF
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 2 Aug 2016 09:24:25 +0100

On Mon, Aug 01, 2016 at 08:52:43pm -0700, Gavin McCullagh wrote:
> Just to satisfy my curiosity, how did this work (or did it?) with TCP SYN Cookies?

The sender of the SYN would simply send the data again once the 3whs completed.

This was before SYN cookies were invented.  As I recall,  I'd stopped using KA9Q
before '96,  which a search indicates is when SYN cookies started.

The KA9Q configuration option was 'tcp syndata',  if you do searches for 'ka9q nos'
you'll find the code if you wish to play (or just read it).

DF

---

From: Joe Touch <[email-masked]>
Date: Tue, 2 Aug 2016 11:04:32 -0700

> The sender of the SYN would simply send the data again once the 3whs completed.
An important point - it would send exactly the same data again (or if it
sent more data, the overlapping portions never changed).

Joe

---

From: "Black, David" <[email-masked]>
Date: Thu, 4 Aug 2016 00:31:26 +0000

<WG CHAIR HAT OFF>

Catching up on a long thread, and commenting as an individual ...

I concur with most of Joe's comments.

Many of Joe's comments are to the effect that behavior here needs 
o be unambiguously specified as for TCP-ENO only.  The initial
bullet list was for the most part, as it was introduced by:

>> MUST discard the data in a received SYN+ENO segment if

although Joe is right about "encryption" needing to be qualified as
specific to TCP-ENO.

> again "that host" or "TEP-protected host", but would say MUST here

I concur with Joe that MUST is appropriate here, as there's no way to exclude
the possibility that the other host is not (or no longer) what someone thinks
it is/was, and in that circumstance, the only sure way to cause the necessary
discard of the SYN-only data is a reset.

Prior list discussion about same IP (or even same IP & port) promising ENO
support is not robust to a NAT reboot with complete state loss.

> >    segments only if explicitly requested by the application

Usual IETF practice is to require implementation of mechanisms when there
are circumstances that require them (to need but not have is bad).  On that
basis, that first "SHOULD" ought to be a "MUST".

The second sentence would be better phrased as a "MUST" for the
default configuration - that would allow additional means of turning
on SYN-only data for an admin who knows what she's doing.  Separate
requirements about when SYN-only data "SHOULD" or "SHOULD NOT"
be used would be fine.

</WG CHAIR HAT OFF>

Thanks, --David

> -----Original Message-----
> From: Tcpinc [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Monday, August 01, 2016 11:53 AM
> To: David Mazieres expires 2016-10-29 PDT; Kyle Rose; Jeremy Harris
> Cc: tcpinc
> Subject: Re: [tcpinc] TCP's treatment of data in SYN packets
> 
> 
> 
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Joe Touch <[email-masked]>
Date: Wed, 3 Aug 2016 17:37:48 -0700

Hi, David,

One suggestion...

> requirements about when SYN-only data "SHOULD" or "SHOULD NOT"

FWIW, my usual expectation is that SHOULD/SHOULD NOT always describes
the requirements of an exception. I.e., if there's a reason to give
wiggle room, it should be stated.

Joe

---

From: "Black, David" <[email-masked]>
Date: Thu, 4 Aug 2016 00:55:45 +0000

> wiggle room, it should be stated.

+1 - that's a good general principle, and I think some of the ADs are now
reviewing for that ...

Thanks, --David

---

From: David Mazieres <[email-masked]>
Date: Thu, 04 Aug 2016 18:21:27 -0700

Okay, guys.  Thanks for the feedback.  Here's yet another attempt at
revamping the section.  I made sure each SHOULD is followed by an
exception.  Note I made one other change, which is to allow SYN-form ENO
options with no suboptions.  Before that didn't make sense, but now it
does as a way of saying "I don't want to encrypt, but I threw away your
SYN data."

Once we converge on this I will release yet another draft...

Thanks,
David

   A host sending a SYN+ENO segment MUST NOT include data in the segment
   unless the SYN TEP's specification defines the use of such data.
   Furthermore, to avoid conflicting interpretations of SYN data, a
   SYN+ENO option MUST NOT include a non-empty TCP Fast Open (TFO)
   option [RFC7413].

   Because a host can send SYN data before knowing which if any TEP will
   govern a connection, hosts implementing ENO are REQUIRED to discard
   data from SYN+ENO segments when the SYN TEP does not govern the
   connection or when there is any ambiguity over the meaning of the SYN
   data.  This requirement applies to hosts that implement ENO even when
   ENO has been disabled by configuration.  However, note that
   discarding SYN data is already common practice [RFC4987] and the new
   requirement applies only to segments with ENO options.

   More specifically, a host that implements ENO MUST discard the data
   in a received SYN+ENO segment if any of the following applies:

   o  ENO fails and TEP-indicated encryption is disabled for the
      connection,

   A host discarding SYN data in compliance with the above requirement
   MUST NOT acknowledge the sequence number of the discarded data, but
   rather MUST acknowledge other host's initial sequence number as if
   the received SYN segment contained no data.  Furthermore, after
   discarding SYN data, such a host MUST NOT assume the SYN data will be
   identically retransmitted, and MUST process data only from non-SYN
   segments.

   If a host sends a SYN+ENO segment with data and receives
   acknowledgment for the data, but the SYN TEP governing the data is
   not the negotiated TEP (either because a different TEP was negotiated
   or because ENO failed to negotiate encryption), then the host MUST
   reset the TCP connection.  Proceeding in any other fashion risks
   misinterpreted SYN data.

   If a host sends a SYN-only SYN+ENO segment bearing data and
   subsequently receives a SYN-ACK segment without an ENO option, that
   host SHOULD reset the connection even if the SYN-ACK segment does not
   acknowledge the SYN data.  The issue is that unacknowledged data may
   nonetheless have been cached by the receiver; later retransmissions
   intended to supersede this unacknowledged data could fail to do so if
   the receiver gives precedence to the cached original data.
   Connection resets are potentially avoidable if SYN data caching is
   empirically found not to occur, or in response to an API command (for
   cases where a higher-layer integrity check would anyway terminate a
   garbled connection).

   To avoid unexpected connection resets, ENO implementations MUST
   disable the use of data in SYN-only segments by default.  Such data
   MAY be enabled by an API command.  In particular, implementations MAY
   provide a per-connection mandatory encryption mode that automatically
   resets a connection if ENO fails, and MAY enable SYN data in this
   mode.

   To satisfy the requirement of the previous paragraph, all TEPs SHOULD
   support a normal mode of operation that avoids data in SYN-only
   segments.  An exception is TEPs intended to be disabled by default.

---

From: Joe Touch <[email-masked]>
Date: Fri, 5 Aug 2016 14:16:16 -0700

Hi, David,

This seems reasonable to me. Thanks for taking the time to work through
this issue.

Joe

---

From: "Black, David" <[email-masked]>
Date: Fri, 5 Aug 2016 22:52:19 +0000

Hi David,

> >    cases where a higher-layer integrity check would anyway terminate a

This leaves specification of circumstances in which it's ok not to reset the
connection to a future draft that explains why that's ok.

Thanks, --David

> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, August 05, 2016 5:16 PM
> To: David Mazieres expires 2016-11-02 PDT; Black, David; tcpinc

---

From: Joe Touch <[email-masked]>
Date: Fri, 5 Aug 2016 20:22:39 -0700

Good catch.  I agree. 

Joe

> On Aug 5, 2016, at 3:52 PM, Black, David <[email-masked]> wrote:
> 
>>>   acknowledge the SYN data.

---

From: "David Mazieres" <[email-masked]>
Date: Fri, 05 Aug 2016 21:40:08 -0700

> connection to a future draft that explains why that's ok.

I'm not sure I understand your suggestion.  Wouldn't changing the SHOULD
to a MUST preclude the future work you are suggesting?  I'm hoping to
reserve MUST for things that prevent future TEPs from conflicting with
one another or with TFO, not to prevent a future TEP from shooting
itself in the foot.  Shouldn't we decide whether or not it's okay to
violate this recommendation if and when somebody proposes a TEP that
violates this rule (presumably armed with a giant measurement study)?

Also, following the previous discussion, I've looked over the "SHOULDs"
in the document, and many of them are not followed by an explicit
exception.  Let me group them here to get your feedback about whether
this is a problem, and whether I need to be more specific in the
document.  Here's a list of types of SHOULD that are not immediately
followed by an exception:

* Many of the uses concern APIs that implementations SHOULD provide.
  The reason for the SHOULD is that in some cases this may be impossible
  or inapplicable.  For example, if you are implementing TCP-ENO inside
  a dedicated NAS server, there might not be the same notion of
  applications giving API commands.  On the other hand, these points are
  pretty important to the success of TCP-ENO, and should be followed in
  the vast majority of cases.

* "TEP specifications SHOULD refer to hosts A and B to specify
  asymmetric behavior."  Again, no explicit exemption, but the point is
  that there might be a TEP that is not asymmetric, or where some other
  optimization makes it better to specify hosts by the numeric order of
  their Diffie-Hellman parameters or something.  I suppose I could
  change that to a MAY, but if TEPs talk about active/passive openers,
  that could mess up simultaneous open.

* Implementations SHOULD provide forward secrecy.  The important point
  is that the TEPs MUST be amenable to forward secrecy.  We didn't say
  MUST for the implementation because that may not always be
  possible--e.g., implementation considerations may someday require
  keying material to be shared across servers or with a load-balancer or
  something.  We don't want to say you can't implement TCP-ENO under
  such circumstances, but we want people to think long and hard about
  the implications for confidentiality.

* Applications SHOULD authenticate endpoints, SHOULD treat session IDs
  monolithically, SHOULD use the application aware bit.  Again, these
  are all obviously very good things.  But there are so many different
  things an application can do, and so many constraints applications can
  be subject to, that it seems inappropriate for a transport-layer
  document to use MUST in regards to applications.  Anyway, we can't
  enforce what applications will do.

* Applications SHOULD migrate to option TBD from the ExID.  RFC7413 used
  the word SHOULD for exactly the same point in its IANA considerations
  section, so we just copied what those authors did.  The TCP-ENO team
  is clearly not well versed in the practice of allocating and
  specifying TCP option kind numbers, so we are happy to follow any
  specific guidance from the working group on whether to change that
  SHOULD to a MUST.

* TEPs SHOULD compute session IDs using only well-studied and
  conservative hash functions.  Here the problem is that the terms
  well-studied and conservative are subjective.  So while I think it's
  an important point people need to worry about violating, the point is
  also nebulous enough that I don't see how to enforce it with a MUST.
  Put another way, the hash functions SHOULD be as conservative as
  practical, with an implicit exception where more conservative hash
  functions are not practical.

* We say the non-SYN-form ENO option SHOULD be 0 bytes if not otherwise
  specified by the TEP, but I'll change that to a MUST in the next
  draft, since it doesn't matter anyway.

Thanks,
David

---

From: Joe Touch <[email-masked]>
Date: Sun, 7 Aug 2016 10:43:08 -0700

On 8/5/2016 9:40 PM, David Mazieres wrote:
> ...
The problem with SHOULD for APIs is that users then can't rely on any of
those features. So the real question is:
    - what are the API features that are absolutely required
    - why are you listing any that are optional?

For APIs, the second set ought to be optimizations, not features or
capabilities IMO.

>   that could mess up simultaneous open.
Are you saying it's better to be symmetric? If so, why?

If not, are you saying that it's more typical that TEPs will be
symmetric? In that case, you shouldn't be using 2119 keywords.

>   is that the TEPs MUST be amenable to forward secrecy.
That MUST turns the SHOULD into a MUST too.
>   We didn't say
That consideration is too vague to weaken a MUST into a SHOULD, IMO.

Why not "MUST provide forward secrecy" and indicate that any future
sharing is viable only when it preserves forward secrecy?

>   enforce what applications will do.
If you say SHOULD, you need to indicate the conditions under which apps
would do otherwise.

Simply saying "we don't know what they want" isn't enough - you're
providing a framework and app choices have implications in the
capabilities provided.

E.g., authenticating endpoints kills BTNS-style PKI-free use - but it's
very clear that if you drop authentication, you're allowing MITM attacks
but also raising the bar against off-path attacks.

>   specific guidance from the working group on whether to change that
MUST serves to deprecate ExID use faster. IMO, you should say MUST
initiate using the new option and MAY continue to support the ExID for
compatibility with development implementations.

If you change the protocol so those development variants aren't
something you want to continue to deal with, then just say MUST and move on.

There's nothing technically wrong with the SHOULD text in RFC7413, but
it shot themselves in the foot IMO by requiring continued legacy support.

>   functions are not practical.

If there is no objective definition of the requirement, then you really
have no business stating it.

Just talk about what constitutes a good hash functions, even
subjectively. Leave requirements to objective conditions.

>   draft, since it doesn't matter anyway.

I would encourage you to be relatively explicit in what the sender
should do. Leaving it vague complicates receiver processing.

Joe

---

From: Kyle Rose <[email-masked]>
Date: Sun, 7 Aug 2016 20:57:54 -0400

> sharing is viable only when it preserves forward secrecy?

I'm not sure we should constrain the protocol on the grounds of preference.
The charter says:

q( encryption and integrity protection with forward secrecy with a
per-connection granularity, )

which tcpcrypt is going to provide. I don't think this implies a
requirement that the protocol used to fulfill the WG charter not be able to
negotiate non-FS security. How do others feel about this? I'm happy to flag
this as a point for security area review, to decide whether forward secrecy
is a MUST for this or even for all future protocols.

> providing a framework and app choices have implications in the

Agreed. I don't think this language belongs in the draft. Authenticating
endpoints is good security practice because it eliminates certain classes
of attacks, but given that the WG's charter is to provide unauthenticated
encryption to foil ubiquitous passive surveillance, I'm not sure that
guidance belongs here.

Kyle

---

From: Joe Touch <[email-masked]>
Date: Mon, 8 Aug 2016 10:00:30 -0700

On 8/7/2016 5:57 PM, Kyle Rose wrote:
> On Sun, Aug 7, 2016 at 1:43 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>

FWIW, I don't care what you pick, but there's no MUST in this doc that
regards this preference.

The MUST needs to apply either to a specific protocol mechanism (flag,
option, etc.) or TEP configuration constraint.

"amenable" isn't a something a protocol implementer or designer can act
on easily.

Joe

---

From: David Mazieres <[email-masked]>
Date: Mon, 08 Aug 2016 11:21:28 -0700

> For APIs, the second set ought to be optimizations, not features or

Because the very notion of an API is optional in some cases.  An
embedded single-purpose network device might not be implemented in terms
of sockets or anything else, but rather might have the device
functionality completely intermingled with the protocol implementation.
Since TCP-ENO is above all a protocol, there's no reason to deem such
implementations non-compliant.  On the other hand, if this ships with
the linux kernel and there's no API call to get the session ID out of
the kernel, we have a problem.

If this occurred only once in the document, I could add a sentence about
the requirement applying only when there's a narrow interface to TCP
such as a socket system call interface.  Since there are multiple
requirements about the API, it would get tedious to repeat such a
sentence.

> symmetric? In that case, you shouldn't be using 2119 keywords.

Okay, how about these lines:

TEP specifications MUST NOT refer to the active and passive opener or
the client and the server as a means of specifying asymmetric behavior,
as such role assignments are ill-specified in the case of simultaneous
open.  Rather, asymmetric TEP behavior SHOULD be specified in terms of
hosts A and B, unless a TEP contains its own symmetry-breaking
mechanism.

> sharing is viable only when it preserves forward secrecy?

The current phrasing was in response to feedback from Yoav Nir (message
ID [email-masked]):

https://www.ietf.org/mail-archive/web/tcpinc/current/msg01026.html

Specifically, he wrote:

        Section 4:
           o Specs MUST NOT allow the negotiation of encryption modes
              that do not provide forward secrecy some bounded, short
              time after the close of a TCP connection.

        That's not up to the specs. The best that specs can do is to
        *allow* forward secrecy by not requiring that session keys be
        derived from long-term keys and inputs sent in the
        clear. Nothing in any spec that mandates ECDHE, for example,
        prevents an implementation from hard-coding a key pair, or
        generating one just once.

So the use of SHOULD is an attempt to make people doing some of the
things Yoav talks about at least think through the implications.

However, in retrospect, perhaps Yoav was objecting to the fact that
Specs was the subject of the sentence, in which case it would be okay to
say MUST for implementations providing forward secrecy.  I would prefer
that, because forward secrecy is important.

> but also raising the bar against off-path attacks.

Okay, well I'll fiddle with the document in an attempt to change some
SHOULDs to MUST or MAY.  It could be that I can use a scoped MUST
instead of a SHOULD in some places.

> it shot themselves in the foot IMO by requiring continued legacy support.

Well, you seem to be the option enforcer, so if you are happy with MUST,
I'll be glad to swap that out.

> subjectively. Leave requirements to objective conditions.

So... lower-case should?

I wish there were some way to specify important points to think about
that just aren't specific enough to be requirements.  This is what
RFC6919 proposes be introduced by "OUGHT TO"... (Although I do note
there's non-April-fools use of this term in RFC2616.)

David

---

From: Joe Touch <[email-masked]>
Date: Mon, 8 Aug 2016 16:34:06 -0700

On 8/8/2016 11:21 AM, David Mazieres wrote:
> Because the very notion of an API is optional in some cases. 

The point of the API is to indicate how the layer above TCP interacts
with TCP.

>  An

That is an implementation issue. The API is an architectural one.

> implementations non-compliant.  

A protocol without an API is not a protocol anymore. A protocol is
*defined* by the API it creates (to the upper layers), the API it
expects (from the lower layers; for link protocols, this is the link
wiring), the messages it exchanges, the state it keeps, and the rules
that govern how these 2 APIs, messages, and state interact.

> On the other hand, if this ships with
You have a problem if you bundle it with an app and the app needs to get
at the session ID and has no way to do so as well.

That's the same problem - an incomplete implementation.

> requirements about the API, it would get tedious to repeat such a
An API is *instantiated* in a socket interface in Unix, but not in other
OSes.

Think of the API as only the calls that TCP imports/exports to any other
program that uses TCP as a transport.

Joe

---

From: David Mazieres <[email-masked]>
Date: Mon, 08 Aug 2016 17:42:26 -0700

> that govern how these 2 APIs, messages, and state interact.

So what do you suggest concretely?  Should we say that implementations
MUST provide certain APIs?  Or that implementations SHOULD provide
certain APIs unless precluded by implementation constraints?

David

---

From: Joe Touch <[email-masked]>
Date: Tue, 9 Aug 2016 09:16:28 -0700

> certain APIs unless precluded by implementation constraints?

Just say that the API MUST support certain features.

See Section 1.4 of RFC793 - even though it doesn't use MUST, that is
implied. The point is that you can implement TCP all you want, but a
*compliant* version of TCP must include some form of interface to the
upper layer "user" application for each of the capabilities indicated.

So you can "bundle" all you want, but if you refuse to let the app layer
issue an URG, you're not TCP.

Joe

---

From: "Black, David" <[email-masked]>
Date: Wed, 10 Aug 2016 15:36:13 +0000

Picking up just this topic ...

> to a MUST preclude the future work you are suggesting?

No, a future experimental (or standards track) RFC could revise that MUST.

> I'm hoping to

It's fine to encourage future work and observe that the results could change
the MUST in the future,  but this distinction between conflicts and self-damage
appears to be false - the problem occurs on a system that does not implement
TCP-ENO or whatever TEP is being used, so something else's "foot" is getting
"shot" ;-).

Bottom line - IMHO,  the current risks with delivery of unacknowledged
cached data by non-ENO implementations (IMHO) justify a "MUST" for 
connection reset that ensures discard of data sent in an initial SYN-only
packet.  Such a  "MUST" is not permanent (particularly in an experimental
RFC) - it can be changed in the future by another RFC.

Thanks, --David