Re: [tcpinc] draft-bittau-tcpinc-tcpeno-02

["Scharf, Michael (Michael)" <[e-mail]>]

I provide some further explanation inline, but I don't have bandwidth for detailed tcpinc discussions. TCP stack vendors would have to speak up for some of these questions, IMHO.

> -----Original Message-----
> From: Tcpinc [mailto:[e-mail]] On Behalf Of David
> Mazieres
> Sent: Sunday, September 20, 2015 9:58 PM
> To: Scharf, Michael (Michael); tcpinc
> Subject: Re: [tcpinc] draft-bittau-tcpinc-tcpeno-02
> 
> "Scharf, Michael (Michael)" <[e-mail]> writes:
> 
> > I have read draft-bittau-tcpinc-tcpeno-02, given that the topic seems
> > related to other TCP modifications. Below are a couple of comments;
> > some could be more major than others. Disclaimer: I don't have much
> > cycles to look into tcpinc, i.e., I apologize if some aspects been
> > discussed already.
> 
> Thanks for the detailed feedback.  I believe we can address many of
> your
> comments pretty easily.  Most of the others would depend on WG
> consensus, but the draft could be adopted either way.  There's only one
> suggestion I think would be problematic to adopt, which is in your
> comments on section 4.  I'll go through each point.

There is actually a very simple solution for section 4. As none of this content seems to be required for an interoperable specification of the TCP option, just move all content in Section 4 to one or more other drafts. KISS principle.

For instance, the session ID could just be a short draft of its own. To me, that would be a much more future-proof concept, e.g., if it should turn out that the session ID format has to be changed in future, but the SYN option format can stay as it is. Or the other way round. Many IETF solutions are specified in more than one document, to have a modular solution.

> > * Abstract, page 1: The abstract confuses me. Should the sentence
> "The
> > TCP Encryption Negotiation Option (TCP-ENO) addresses both of these
> > problems" imply that this document shall finally also specify the
> > encryption within the transport layer, being the second problem? Why
> > doesn't the abstract simply focus on negotiation and mention that it
> > specifies an option limited to the TCP three-way-handshake to solve
> > the negotiation problem?
> 
> The abstract here is just trying to give motivation.  So by addresses
> we
> didn't mean solves.  TCP-ENO does not solve either of those problems
> without an encryption spec, but is motivated by both.  Would it help if
> instead of "addresses" we said "is motivated by"?

My point is to have an abstract that focuses on what this document seems to be about. As far as I can see, this document seems to specify a TCP option during the 3-way handshake that enables negotiation of encryption. Why don't you just write that in the first or second sentence so that the reader can find the key message fast?
 
> > * Section 2, page 3: To me, the whole text on page 2 includes too
> much
> > hand-having. Some examples: The relation between this document and
> EDO
> > is unclear and not further detailed later. The socket interface is
> not
> > owned by the IETF, and RFC 3493 is an informational document for IPv6
> > only. It is not clear how TFO (RFC 7413) would be used together with
> > this option, and, if so, if stack vendors would be interested in
> > deploying both options together. Basically, I think page 2 could be
> > removed entirely without affecting the content of the document.
> 
> Removing this text seems fine.  It's partly there just to provide some
> context/motivation for the working group, so perhaps this is the sort
> of
> thing we could remove after adoption.  There's a longer argument to be
> made for each of these points, but it doesn't really belong in the
> TCP-ENO document itself, so killing the text might be a reasonable way
> forward.
>
> > * Section 2, page 4: "Provide signaling through which applications
> can
> > better take advantage of TCP-level encryption (for instance by
> > improving authentication mechanisms in the presence of TCP-level
> > encryption)." Since authentication is listed here: How does this
> > option interact with TCP-AO? For instance, I think this document
> could
> > perhaps discuss what a receiver may do if a SYN segment both with
> > TCP-ENO and TCP-AO options is received. This is a question much
> closer
> > to the SYN handshake negotiation mechanics than various other
> sections
> > of the document.
> 
> The higher-layer authentication taking advantage of TCP-level
> encryption
> is at a higher layer than TCP-AO.  In particular, it would take place
> by
> exchanging bytes over the TCP connection itself.  Hence, I see only one
> reasonable approach:  First check TCP-AO.  If TCP-AO discards the
> packet, then TCP-ENO is irrelevant.  Otherwise, proceed as usual with
> TCP-ENO.
> 
> Does that make sense to you?  And is it worth detailing in the
> document?

Whether any specific processing belongs into the document has to be decided by the WG. Personally, I'd also be fine with mentioning TCP-AO as a topic for further experimentation.

> > * Section 3, page 5: Regarding the sentence "Encryption specs MAY
> > include extra bytes in a non-SYN ENO option, but TCP-ENO itself MUST
> > ignore them." and Figure 2: I suggest to keep this document entirely
> > self-contained, which to me means something like: "If a non-SYN
> > options contains extra bytes, TCP-ENO itself MUST ignore them." If a
> > protocol negotiated by TCP-ENO indeed needs further TCP option space,
> > this should be documented in the corresponding protocol
> specification.
> 
> I'm going to lump this together with your next comment.
> 
> >   - Option kind sharing: For this spec, it is sufficient to specify
> >   how the option is used within this specification. This section can
> >   thus be removed entirely.
> 
> I agree that how to do option kind sharing is a property of encryption
> specs, not TCP-ENO.  However, the fact that TCP-ENO is amenable to such
> sharing is an attractive property.  So it seemed useful somewhere to
> record the fact that this property isn't just an accident.  If someday
> somebody proposes an encryption spec that shares ENO's option kind, we
> don't want them to meet resistance on the grounds that they are
> squatting on a different RFC's option kind.

I cannot follow. Every protocol designer knows that a protocol can be extended if a protocol does not make use of certain messages, and this does not require explanation. Also, the IETF can update the document any time in future if those bytes are required.

Sorry, if your motivation is to have this section as a means to bypass the IETF process in future, then having these statements is not acceptable *AT ALL*.

Apart from that, it could happen that an enhanced version of TCP-ENO (e.g., a follow-up spec on standards track) needs some option space e.g. in the first ACK for some more advanced negotiation, right? If so, it is not clear whether that extra byte space is completely available to TCPINC encryption specs, or whether TCP-ENO may need it itself in future. Thus, to me the statement in the current draft is not even future-proof for TCP-ENO alone.

The usual way the IETF deals with this is a sentence like "Extra bytes in non-SYN are reserved for future use, and TCP-ENO itself MUST ignore them". What prevents you from writing that?

> So basically the intent of section 4.2 is A) to serve as a reminder not
> to mess up this sharability property as we edit the draft, B) to avoid
> resistance for specs that do such sharing, and C) to serve as a strong
> suggestion to any future TCP-ENO revisions to confine themselves to SYN
> segments.  Would you be happier if we moved it to an appendix?  Or
> maybe
> we could leave it in as a reminder while the document is being edited,
> and then take it out at the last minute?
> 
> > * Section 3.2, page 7: I am confused by some RFC 2119 language in
> this
> > section. Examples:
> >
> >   - "More precisely, for negotiation to succeed, the TCP-ENO option
> >   MUST be present in the SYN segment sent by each host" =>
> >   lower-capital or (better) reword to required implementation
> behavior
> >
> >   - "Additionally, the ENO option MUST be present in the first ACK
> segment sent by each host, so as to indicate that no
> >    middlebox stripped the ENO option from the ACKed SYN." => lower-
> capital or (better) reword to required implementation behavior
> >
> >   - ... (several further examples of the same form)
> 
> I see.  Is the issue that the MUST isn't really associated with an
> action on the part of an endpoint?  So would an informal description
> ("TCP-ENO can't work unless A, B, C"), followed be a more active
> "implementations MUST disable encryption if..." be better?

Yes, I suggest to rephrase those sentences to describe required active behavior of a protocol implementation.

> > * Section 3.2, page 7: "An active opener begins with a SYN-only
> > segment, and hence must send two segments containing ENO options."
> > That "must" would be a candidate for RFC 2119, but in fact I think
> the
> > sentence is actually even wrong, given that an active opener "must"
> > only send ENO options in the first segment for the fallback case.
> 
> Indeed, good catch.
> 
> > * Section 3.2, page 7: The protocol specification has to correctly
> > specify the behavior for retransmitted segments with SYN flag. The
> > requirement stated on page 12 probably belongs here.
> 
> That should be pretty easy to address.
> 
> > * Section 3.2, page 9: "... and MUST NOT present raw TCP payload data
> > to the application." Please specify the behavior for payload data in
> > SYN segments, or explicitly mark it as in-scope of a protocol
> > specification using this option. TFO (RFC 7413) could be relevant in
> > this context.
> 
> Really the point is just that you want to make sure you don't end up
> with one side encrypting, and the other side not encrypting.  What we
> mean to say is that receiving an ACK segment with an ENO option is the
> point of no return.  That implies that whatever is in TCP's payload
> isn't what the application is writing.  But I agree talking about key
> agreement and such may be too specific here.  It would probably be
> clearer just to talk this in terms of enabled/disabled encryption.

My comment is not about key agreement, but about the fact that data in SYNs is allowed by the TCP protocol specification. Specifically, a receiver could receive a SYN with an ENO option and payload data. Now, the question is what the receiver shall do with that payload. I think this document has to comment on that. Note that - without TFO - the recipient can delay the delivery of that data to the app until the hand-shake completes, i.e., at first sight the receiver knows whether a TCPINC protocol is indeed enabled or not before it has to decide what to do with SYN payload. Thus, I guess this situation can be sorted out even for fallback, with some additional wording in the spec. With TFO, the situation may be more complex.

This document could leave the combination of TCP-ENO and TFO as a topic for further experimentation. But personally I'd be concerned if the IETF specifies more and more TCP options being mutually exclusive.

> > * Section 3.3, page 10: Protocol stacks on top of TCP can be complex
> > and consist of multiple layers, libraries, etc. "application" is not
> > well-defined in this case, and whether an application indeed can be
> > aware of TCP stack internals, or not, is a relatively complex
> > question. The concept of "application-awareness" in a multi-layer
> > stack seems fuzzy to me, with lots of open questions. As a simple
> > remedy, instead of "application-aware", the document could perhaps
> use
> > a term like "upper layer protocol aware".
> 
> Yup, that sounds like a good suggestion.  (In fact, the companion
> tcpinc-api informational document tries to shed some light on this, and
> the suggested API changes are right on top of the socket layer, so very
> low level.)
> 
> > * Section 4: I don't understand why any of the content in the whole
> > section 4 is needed for interoperable implementations of a TCP option
> > in SYNs. Specifically:
> >
> >   - Requirement list: In the IETF, requirement lists are typically
> >   useful during WG operation, but they can easily become outdated,
> >   e.g., by trends in the market. There has always been lots of
> >   research innovation in TCP, and I could imagine that the TCP-ENO
> >   negotiation option could find future interesting use outside of
> what
> >   is known today.
> >
> >   - Session ID: To me, the definition of session IDs, if at all, has
> >   to be done in specification of the encryption spec. I don't
> >   understand why this section is needed for building interoperable
> >   implementations of TCP-ENO, in particular, if not even the length
> is
> >   defined (and that length definition does not belong in this
> >   document, IMHO).
> 
> I think this is the one area where it would be harder to incorporate
> your feedback.  The reason is that the main value of TCP-ENO is that it
> can abstract away the differences between different TCP-layer
> encryption
> schemes for applications.  So if I write an application that uses
> TCPINC
> today, and tomorrow there's some new spec that takes advantage of TFO
> or
> something, my application should still work unmodified TCP with the new
> encryption spec.  This is only possible if there are certain standards
> for how a TCP-ENO spec behaves.

I cannot follow. To me, this mixes up TCPINC and TCP-ENO specs. As far as I understand, a TCPINC protocol has two interfaces, and TCP-ENO is only one of them. To me, TCP-ENO seems to be about a simple TCP option during the three-way handshake, and one or more TCPINC protocols have to allocate code-point(s) to enable negotiation and implement the SYN processing according to the spec. But whether different TCPINC encryption specs implementations on different OS indeed have the same user interface, e.g. on Linux and Windows, does not matter for their implementation of the TCP-ENO option, as long as they are compatible in the SYN. This is about two completely separate interfaces that affect different parts of the operating system, which also have separate innovation cycles. For instance, at some point in time TCP-ENO SYN handling may want to be implemented inside TCP hardware offload engines. Updating that is a completely separate question from updating an OS kernel, a user space library, etc. And if Windows and Linux provide a different application interface, you can still sort that out in an OS-independent middleware. That is not possible for TCP SYN options.

My suggestion is to limit this document to what is needed to have interoperable implementations of the TCP option during 3-way handshake. This is core IETF business and a relatively straightforward document. KISS.

Application interfaces can be discussed in separate documents (provided that operating system vendors back corresponding standardization in the IETF).

> To make this concrete, suppose a spec behaves as currently described in
> the TCP-ENO draft, and an application starts digitally signing the
> Session ID to authenticate the client to the server.  That's a
> perfectly
> reasonable use of Session IDs as we envision them.  Now say a later
> spec
> allows the client to determine the session ID.  That means all these
> signed messages from past authentications are now effectively "blank
> checks" that servers can use to impersonate clients to other servers.

I don't question the potential value of session IDs. I just suggest to move them into a separate document, which can possibly refer to the TCP-ENO option spec.

If the draft that specifies a session ID was only a short 5-page I-D, this would even be better. KISS, as I said. 

> > * Section 5: So far, the IETF has only rather limited credibility in
> > specifying TCP API extensions, at least in my experience. Given that,
> > this section could e.g. be moved to an appendix (see e.g. RFC 7413).
> 
> Well, RFC7413 actually specifies the API changes in the appendix.  In
> our case, following the TCPINC charter, we don't even want to put the
> suggested changes in the experimental RFC, but rather an informational
> one.  We've proposed a draft for that informational document here:
> 
>         https://tools.ietf.org/html/draft-bittau-tcpinc-api-00
> 
> So given that there will exist a separate informational document with
> an
> example API, a reasonable question would be whether to mention this at
> all in the ENO spec.  I think it's nice to remind implementers that
> they
> SHOULD provide some sort of API (even if not the example one), but I
> don't feel very strongly about it.  My preference might be to leave it
> in, but if the WG wants to remove it, then that's fine, too.  It's just
> a couple of sentences that won't otherwise affect anything the draft.

I've not read draft-bittau-tcpinc-api-00. Whether TCP stack vendors would indeed care about such IETF specifications has to be sorted out. As an author of RFC 6897, I had to learn myself some lessons in that space, but this was in another WG. 

> > * Section 6: Further topics to be considered here:
> >
> >   - Considerations of the space limitation in SYNs. Since this
> >   document allows in principle an arbitrarily long TCP option,
> >   discussion and guidance on that seems useful.
> >
> >   - Compatibility with other TCP extensions. Unless sorted out in
> this
> >   document, potential interactions and/or incompatibility with TCP-
> AO,
> >   MPTCP, TCP Fast Open, etc. should at least be mentioned as open
> >   issue.
> 
> These are good points to mention.
> 
> > * Section 8: The IANA registration procedure for "cs" values has to
> be
> > specified, and I could imagine different variants, which should
> > probably be discussed relatively early.
> 
> Any suggestions or examples of other RFCs whose lead you think TCP-ENO
> should follow?

See RFC 5226

My own experience as document shepherd is that IANA sections are rather carefully reviewed by the IESG, with interesting outcomes. Therefore I leave it up to people more familiar with IANA procedures to suggest something.

But based on my own experience it makes sense for a WG to consider this question at *very* early stage.

> > * Section 8: Why does TCP-ENO not allocate an TCP Experimental Option
> > Experiment Identifier according to RFC 6994? That would be an easy
> > solution to enable experiments with multiple interoperable
> > implementations over the Internet, prior to assignment of a TCP
> option
> > kind number. Keep in mind that an experimental document requires an
> > explicit IESG action for TCP option kind assignment. In the past, TSV
> > has asked for this IESG action several times. In those cases, there
> > has been very strong consensus in the corresponding working group
> > regarding the codepoint assignment, backed by reasonable interest by
> > TCP stack vendors in the protocol.
> 
> The WG has debated this point before, and there didn't seem to be
> consensus.  Some favor experimental option kinds.  Others believe this
> will cause problems when we switch from experimental to regular.  (If I
> recall, an example of that problem was NAT-T.)
> 
> The reality is that we've been using option kinds 69 and 70 in the wild
> for encryption for many years, in software that's available for several
> OS distros.  Before that, options 16 and 17 were allocated to
> encryption
> and could safely be reused given that the old encryption scheme is no
> longer or was never in use.  IANA has marked 69-70 as "Reserved (known
> unauthorized use without proper IANA assignment)."  Realistically, at
> this point the main danger is that our use of 69-70 annoys people, not
> that we collide with other users in the wild.  (Plus, TCP-ENO's option
> kind sharing means only one kind is required, not two.)

I'll not comment on these statements on TCP option code-point squatting, even if I probably should.

As a side note, it is perfectly possible that the IESG will neither allocate 16, 17, 69, nor 70 to TCP-ENO, and this may even be appropriate given the prior code-point squatting. And anyway any IETF-compliant protocol spec of TCP-ENO may have to be updated at some point in time, after an IESG decision. My understanding is that many TCP stacks can be updated within weeks as part of the normal OS updates, i.e., there are probably solutions to this in the market.

I'll just state again that the IETF has published RFC 6994 in order to offer a simple solution to avoid TCP option kind code-point squatting. This solution was designed for experiments with interoperable implementations of a protocol spec prior to an IESG decision. For instance, TFO used this process. As far as I understood, the TCPINC working group currently asks for experiments with running code. I don't know how independent implementations of the TCP-ENO spec should interoperate without some guidance on the option code-point, and RFC 6994 would be a simple solution to that. In some sense, the current IANA section text seems like a guideline towards non-interoperable implementations and code-point squatting. This is not acceptable in my point of view.

Michael


> I hope that the lack of consensus on this this point doesn't stand in
> the way of adopting the draft.  We could certainly adapt TCP-ENO either
> way.
> 
> David
> 
> _______________________________________________
> Tcpinc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpinc