"Scharf, Michael (Michael)" <[email protected]> writes:
> My view is that this document has to change significantly before we > can discuss adoption. Since this proposal significantly modifies the > TCP protocol and the TCP state engine, I'd really prefer to *first* > have a consistent document and *then* discuss a potential adoption. If > the consensus in TCPINC is not to use header protection, I think > header protection has to be removed entirely from the protocol > specification - it could go to a separate document. Hi, Michael. I'd like to address some of your points, and attempt to provide and request clarification on others. So long as tcpcrypt is a viable contender, we will of course produce an updated draft to disable default header protection. > I've stated already multiple times that I am really concerned about > the definition of an own option payload encoding for INIT1 and INIT2 > [1]. TCPM has a chartered milestone for EDO to provide long > options. To me, EDO provides what is needed for INIT1/INIT2. If I miss > something here, I am really willing to learn more. I do not think that > the TCPINC working group should define a second and incompatible TCP > long option format. This will very likely result in incompatibility > issues once EDO, TCPINC, and/or other TCP extensions evolve in the > future, or if they will be used in combination. The last thing we need > in the IETF is standardizing multiple incompatible TCP variants each > defining their own encoding of the data stream. This will end up in a > mess. I believe updating draft-bittau-tcpinc-tcpcrypt to use EDO would > only be a small change of the protocol. It seems that you are asking us to move the body of the INIT1 and INIT2 messages into option space using EDO. But TCP-use-TLS does not put the key exchange into option space, either. So on this point are you equally opposed to the TCP-use-TLS proposal? INIT1 and INIT2 are part of the session. For example, it could be necessary for INIT1 to exceed the size of a single TCP segment. Why re-invent TCP to stitch together options over various segments when TCP already has a nice mechanism for reliable in-order data delivery? > If EDO as currently defined was not sufficient for TCPINC, the TCPM > working group would be really open to feedback [2]. Supporting > combinations of TCP-AO, MPTCP, TCPINC, etc. was the main reason why > TCPM decided to start the design of a long option solution. Speaking as a tcpcrypt author, I strongly support the adoption of an EDO option, and believe tcpcrypt would benefit through more graceful coexistence with other options (particularly large SACK blocks). > I also expect that a TCPINC protocol will (hopefully) evolve in > future, and the TCPINC community should therefore develop a > future-proof design. I imagine that future TCPINC enhancements could > need the exchange of additional data, possibly exceeding the 40B > option limit like INIT1/INIT2. In this case, a TCPINC protocol using > the current tcpcrypt payload encoding could easily require further, > very complex long option encoding hacks to be able to transport the > data needed by such TCPINC extensions. As a result, I believe that the > current INIT1/INIT2 encoding is not future-proof and may prevent an > evolution of the TCPINC protocol itself. Again, if I should miss > something here, I am willing to learn more. Can you give an example of why you think this is not future proof? Our INIT messages have a 4-byte magic number and 4-byte length. I can't see any scenario in which we would need more than 4GiB of key exchange data, but if the need really does arise we can just specify new magic numbers with an 8-byte length field. > I am not a crypto algorithm expert. But without the need to offer TCP > header protection, I assume that the unauthenticated encryption > features of tcpcrypt can also be provided by a TLV encoding (or > something equivalent) inside the TCP data stream. I'd assume that the > actual protocol inside the TCP byte stream could be different to TLS > if diversity was an important design objective - this part of the > design has to be sorted out by security experts. In addition to a much > cleaner protocol architecture not interfering with other TCP > extensions, such a TCPINC design would also waste less scarce TCP > option space and seems clearly superior to the current design in > draft-bittau-tcpinc-tcpcrypt. So the way I see the two options we were asked to chose between, TCP-use-TLS uses TLV for both key exchange and data, while tcpcrypt uses TLV for key exchange only (namely INIT1 and INIT2). I think Joe Touch would prefer TLV for neither. You now seem to be advocating a fourth design point which uses TLV for data only. Maybe I misunderstand you, since we've had a number of drafts and no one has yet advocated that design point. I think TLV has disadvantages for data. For example, it may increase latency if authentication doesn't fall on segment boundaries. But non-TLV also has disadvantages, such as consuming options space that could otherwise be used for larger SACK blocks (though EDO could really help here). This is something I would expect the working group to debate. But I don't see any disadvantage to TLV for key exchange. (Possibly you could argue it undermines the "TCPness" of the protocol, but not if you are anyway using TLV for session data.) David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
