John-Mark Gurney writes: > > You can protect replay attacks on the payload by incorporating a sequence > > number into the integrity check. This is how TLS works ordinarily. > > Yes, I did think of a framing protocol (see comments on MAC in > payload), but any framing protocal does immediately increase the > complexity of the protocol...
Not necessarely. Doing tcpinc on separate layer above TCP (i.e between the tcp and the application) does have its benefits, and its complexity is propably less than the protocol using TCP MAC option when making it so that it will work through middle-boxes that split and merge segments. If we want to work through middle-boxes that merge / split segments, we need framing protocol. For the tcpcrypt like protocol, it would need to be inside the TCP MAC option, i.e. the MAC option needs to include stream offset and length over which parts of the TCP stream the data MAC was calculated. This allows other end to regenerate the segments as it was in the transmitter end, so it can calculate same MAC. This kind of reassembly is complex task (just look how many different security vulnerabilities there has been in the IP-reassembly code). This issue is bit similar than why ESP is so much easier to implement than AH. ESP just takes bunch of bytes and encrypt and MAC them, the AH takes bits from here and there, and calculates some fields as zeros, and so on, and getting all that right is quite a lot more complicated than the ESP calculation. > It also prevents the elimination of unnecessary MACs in the case of > retransmits... i.e. person typing on lossy link... Each key press > gets sent, but significant packet loss and have to be retransmitted.. > W/ a framing protocol, you must transmit the MAC for EACH key press > instead of combining them all together in a later packet... Yes, but on the other hand you can combine multiple framing packets to the same TCP segments. You will include framing and MAC overhead several times, but latency is about same, until the extra overhead gets so big that it starts really affect the transmit time. Also note that this kind of lossy slow links are just about the cases where there might be tcp optimizers there that will combine segments, i.e. if you have one slow network connceted to the lossy but faster network, there is benefit for doing the retransmissions from the middle, not from the end, and in that case those tcp optimizers will most likely also merge the segments and fake acks to the end node, and taking care of the retransmissions themselves. If the protocol is using for example TLS framing inside the TCP stream (one of the proposal we have), then that kind of protocol will survice that kind of segment merge without any problems. To make protocol using TCP options to work, we most likely need to hope that the optimizer copies all the options to all of the packets when it merges them, and/or duplicate more information, and/or make overlapping MACs with stream offsets and lengths. This is all more complicated and still unspecified (as far as I know the tcpcrypt currently does not try work through middle boxes which merge or split segments). > This is part of the problem of discussing what a solution should > contain vs what solution to pick... Each solution may choose a > different method, and each one has their trade offs... No framing > protocol was mentioned, nor was replay attacks in the last email, > hence my concern... We are discussing whether the TCP header needs to be protected or not. After we have decided what to do with that, we can start checking out the solutions. If we decide that we do not care about TCP headers, then we can most likely get protocols work over segment splitting/merging middle-boxes easier than if we try to also protect TCP headers through such boxes. > Yes, if a framing protocol is used, and properly protected, then I'll > agree sequence numbers don't need to be protected, but we already have > a framing protocal and it's called TCP/IP.. And we are making new protocol called TCPINC that provides encryption inside the TCP/IP. If we want to go through middle-boxes that merge or split segments, we do most likely need some kind of framing protocol (or at least I have not found out way to go through them without having framing protocol). The framing protocol might be inside the TCP data, or it might be parts of the fields copied from the TCP header to the TCP option to allow segment reassembly, but it is still framing protocol. -- [email protected] _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
