marcelo bagnulo braun wrote this message on Mon, Oct 06, 2014 at 19:01 +0200: > The options we can identify are the following ones: > - Protect only the payload (don't include any of the TCP header fields > in the MAC calculation)
If this does not include the sequence number, then how can we possibly prevent replay attacks? As you discuss later, preventing replay attack IMO should be done as it isn't that much more difficult... > - Protect the payload plus some fields of the TCP header > For this option we believe there are 3 possible approaches: > -- include the MAC (and other relevant information) in a TCP option > -- include the MAC (and other relevant information) in the TCP payload > -- include the MAC for the TCP header fields in a TCP option and the MAC > for the payload in the payload. [...] > Basically, protecting the TCP header would make TCPINC incompatible with > some of the currently deployed middle-boxes and this would result in > different failure modes. We should then consider the different types of > middle-boxes and consider the impact of protecting the TCP header when > these middle-boxesmiddleboxes are on the path. Since different > middle-boxes operate in different fields of the TCP header, it then > makes sense to consider the protection the TCP fields independently. This is an incorrect statement which you correct later about offset sequence numbers... > NATs (and the like). NATs are pervasive and must be supported. NATs > modify the source port. In cases that there is a communication between > two hosts located behind different NATs both the source port and the > destination port are rewritten by the NATs. This basically means that > ports cannot be protected. I agree... Yes, someone might be naughty and redirect your session to a different port on the box, but, then you have an active attacker, and likely other issues... But TCPINC is about getting opportunistic encryption, we need wide deployment, and dealing w/ authenticating who you are talking to is the responsibility of the applications, not this protocol... > TCP proxies. TCP proxies terminate the TCP connection and establish a > new connection to the destination. It is unclear to me whether TCPINC > w/o header protection would work through a TCP proxy. I guess it depends > on whether the proxy will copy the TCPINC option in the SYN packet. I > guess if it does, it would be possible for TCPINC to work through such a > TCP proxy. If it doest, the modification to support it seems straight > forward to implement. If the TCP header is protected, then the TCP proxy > should terminate the TCPINC connection (and possible establish a new one > to the destination). This implies that the TCP proxy needs to be > upgraded to support TCPINC which seems a major upgrade. The failure mode > is gentle in both cases anyway, as if TCPINC is not supported, the proxy > will simply not reply the TCPINC option so a regular TCP connection will > be established without additional latency. Yes, and if supported, some additional work needs to be figured out how to properly pass authentication through such a proxy, which will be "interesting"... > Middle-boxes that rewrite the sequence number (see > http://noahdavids.org/traces/sequence_number_rewrite.html for instance). > Direct protection of the sequence number and ACK number wouldn't be > compatible with these middle boxes. However, it would be possible to > protect the offset of the current payload with respect to the initial > sequence number used in the connection and this would likely work. It isn't just middle-boxes that rewrite sequence numbers, some firewalls and NAT boxes do too... This is neccessary as some boxes choose bad ISN, and having a firewall fix this is a good thing... > Middle-boxes that split segments. In this case, two (or more) TCP > headers are generated by the middle-box for the generated segments. The > new segments will have different values for some of the TCP header > fields, in particular the sequence number will be different and likely > the URG pointer and data will be different if it was set in the original > segment. This implies that direct protection of some of the TCP header > fields wouldn't be possible i.e. the sequence number would be different. > It would be possible to include enough information in the original > segment to allow the receiver to recompose the original segment header > and process that one instead of the received one. It is not clear (to me > at least) what would be the residual threats if this approach is followed. > Solutions that carry the MAC in a TCP option would have additional > challenges. There is evidence [1] that the options will be duplicated in > these cases, so the MAC information will be preserved. However, in order > to reconstruct the original segment, additional information needs to be > carried in the option, possibly requiring more bits of the limited > option space. > > Middle-boxes that merge segments. In this case several original segments > are merged into a single segment. The resulting segment will likely have > the sequence number of the first segment. The sequence number is then > not an issue. According to [1] it seems that duplicated options may be > removed (not clear with this is about the same option with the same > values inside or if it also applies to different values). In any case, > since the option space is limited, it is likely that a single segment > wont be able to carry more than one TCPINC MAC option. this actually is > a problem for the protection of the payload more than it is for the > protection of the header fields. Loosing the TCP option would cause a > failure in the validation of portions of the data. I agree that putting the MAC in the payload is not an option... It would effectively require an additional framing proptocol... As tcpcrypt has found out, putting the MAC in a TCP option appears to work well... > Middle-boxes that remove TCP options. This may be the case of firewalls > that remove options they don't know. This case seems straightforward as > the TCPINC option in the SYN will also be removed and the connection > will fall back gently to regular TCP. > > So, we can now consider the different fields of the TCP header and > evaluate the impact of protecting them. > > Port numbers: clearly we should not protect these. > Sequence numbers: It seems that some of the problems can be addressed by > protecting the offset and not protecting the absolute sequence number. > For other problems, it may be requried to include copy the original > information in the TCPINC signaling to allow the reconstruction of the > original header at the receiver. > ACK numbers, are also affected by segment rewriting, but protecting the > offset could make this work. This IMO is manditory to prevent replay attacks. I'm not sure how else you would short of adding a layer of framing on top... As tcpcrypt has found out, offset sequence numbers works fine, and has the added benefit of preventing sequence number wrap around if you extend the offset to be 64-bits... > Flags: We havent identified any specific problems with protecting the > flags (except for RST messages, that i will leave out of this particular > discussion and we can tackle if we decide to go for TCP header protection). > URG pointer, RCV window, We have not identified specific issues other > than the case of merging segments with different values for these fields > and taking one value from one segment for one field and taking a value > from a different segment for the other one. > Options: Probably more discussion is needed about each fo the specific > options, but this can be done after we figure out if we should protect > or not the TCP header. For flags, we should look at what research has already been done on this topic... From this email, it looks like the existing research (tcpcrypt) has not been consulted... As I'm not a low level TCP person, I'm not as familar w/ what flags should/must be protected... > If we now try to assess the different options we have against the > analysis we have done, we can see that: > (I will use the terms higher, lower and medium to relfect the differenct > features compared to the same feature provided by the other options) > > Option 1 - Protect only the payload (don't include any of the TCP header > fields he MAC calculation) > This seems the option that provides higher deployability, lower security > and lower complexity. This IMO is a non-starter as replay attacks will be trivial in this case... > Option 2 - Protect the payload plus some fields of the TCP header > For this option we believe there are 3 possible approaches: > Option 2.a -- include the MAC (and other relevant information) in a TCP > option > This option seems to provide lower deployability, higher security and > lower complexity Can you include information why you believe that this has lower deployability? > -- include the MAC (and other relevant information) in the TCP payload > These seems harder to assess since there is no full fleshed option that > we can look at. One consideration that needs to be done here is what to > do with pure ACKs that don't carry any data. If we want to carry the MAC > for the header in the payload, we would then have to acknowledge ACKs, > which may be the wrong path. Another possible way doing with this issue Ouch, acks of acks of acks, all the way down... Though protecting payloadless acks seems less than useful, the worse case is that the attacker could cause duplicate data to be sent until the otherside finally sent data, though then the other side could be a target of the attack... But this is probably not that much data... > would be to not protect pure ACKs. In this case, it is unclear how much > we gain compared with only protecting the payload, as packets with > payload are harder to forge as they require a proper MAC. This basically > provide protection against off path attackers but would not provide > protection against on path attackers that can eavesdrop but not > intercept segments. Another option here would be carry the MAC for the > header and the payload and additional information for packets with data > in the payload and to include the MAC for the header in a TCP option in > pure ACKs. This has the benefit that pure ACK are maybe more gently > treated by resegmenting boxes, as there is no data to resegment (but > this is a guess at this point). > In the best case, assuming this last option is viable, this solution > would provide higher security, higher deployability at the cost of > higher complexity. > -- include the MAC for the TCP header fields in a TCP option and the MAC > for the payload in the payload > This is similar to the last option discussed above, only that may be > architecturally cleaner. The main difference is that when options are > lost in resgementation, some MAC information is lost and it is unlikely > that we can convey enough information in the TCP option to reconstruct > the original payload. This seems odd to have two MACs... Though if the MAC option is getting stripped, do we trust the connection? > So, in a nutshell, security, deployabilty and complexity, pick two. > > Now, let's hear your opinion of what tradefoff we shoudl make at thsi point. > > Regards, Tero and marcelo > > [1] Michio Honda, Yoshifumi Nishida, Costin Raiciu, Adam Greenhalgh, > Mark Handley, Hideyuki Tokuda, Is it Still Possible to Extend TCP?, > IMC2011 (see http://conferences.sigcomm.org/imc/2011/docs/p181.pdf) > > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
