Hi, Sorry if I miss the previous discussions, I personally would like to clarify one point. My naive question is if we can do this in some opportunistic ways or we should not allow the risk for downgrading attacks.
This may be technically difficult, but I'm a bit curious if we can go option 2 in most cases and can go or fallback to option 1 (or normal TCP) in a certain cases. Thanks, -- Yoshi On Mon, Oct 6, 2014 at 10:01 AM, marcelo bagnulo braun <[email protected]> wrote: > We have been going through the discussion about whether to protect or not > the header and we conclude that there is no clear consensus on the issue > and we believe the reason is that there is no compelling technical reason > for adopting either of the options but rather there is a multidimensional > trade-off for which the WG will have to make a design choice. > > We believe the 3 main features involved in the trade-off are: > - security i.e. the level of protection achieved by the solution. > - deployability i.e. the level of compatibility with currently deployed > technologies (notably middle-boxes) > - complexity of the resulting solution > > (as a kind of a side note note that it can be argued that both > deployability and complexity affect security since a solution that cannot > be deployed hardly provides any security and a solution that is more > complex is more prone to errors and undetected vulnerabilies). > > So, we believe that the WG has to make a design choice about this issue. > We believe that the WG has disucssed the different considerations involved > in dept and it is ready (or as ready as it can be) to make the choice. We > would like to ask the WG what would be your preference at this point. > > We provide below a summary of the aspects we believe are more relevant and > we present wat we believe are the different options we have at this point. > > 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) > - 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. > > We next describe some of the relevant considerations we identified and how > they are impacted by the different choices. > > In order to frame the discussion, we should first consider the different > types of attacks and decide whether the TCPINC solution should provide > protection against them. > We can first consider passive eavesdropping. There is a clear consensus > that TCPINC must provide protection against this. It is also clear that in > order to provide protection against passive eavesdropping there is no need > to provide integrity protection to the TCP header. > > We then consider active man in the middle attacks. Since the main goal of > TCPINC is to provide unauthenticated encryption and integrity protection, > clearly, it is not the main goal of TCPINC to provide protection against > these attacks. > > We can then finally consider off-path active attackers. These attackers > are not located along the path, so they cannot break the unauthenticated > encryption, but they can send packets with forged TCP header. This means > that they can leverage on any unprotected bits to launch their attacks. > Nevertheless, it should be noted that even if the TCP header fields are not > protected, the mere fact of protecting the payload bits makes these type of > attacks more difficult. In particular, fields that make reference to > payload information do require a properly MACed payload (for example, an > attack that uses the URG data, needs actual data in the payload and in > order to be considered by the receiver, the data needs to satisfy the MAC > validation. Similarly an attack that attempts to use sequence numbers > requires actual data in the payload that satisfies the validation of the > receiver. On the other hand, attacks against the flag bits, against ACK > number (these may require further considerations as the actual MACed data > is still flowing), or against the RCV window don't require any data in the > payload hence protection of the payload doenst provide any protection > against these.) Leaving the TCP header unprotected will then enable attack > vectors for these type of attacker that could be prevented if > unauthenticated integrity protection were provided to those bits. > Basically, the default mode of TCPINC (i.e unauthenticated encryption and > integrity protection would be weaker if the TCP header is not protected). > > Another type of attacker is an attacker that is located along path, that > cannot intercept/change the packets that are flowing, but it can see them > and also it can send forged packets (would be a combination of the passive > eavesdropper and the off path active attacker). In this case the attacker > can launch reply attacks or use information in the legitimate packets to > create forged packets. This type of attackers can then obtain a properly > MACed payload and use it to launch attacks against those TCP header fields > that we implicitly protected by MACing the payload and other relevant > information needed such as valid sequence number and ports used in the > connection. So, explicit MACing of the TCP header fields would protect > against these attackers. > > So, from this perspective, not protecting the TCP header bits would result > in a weaker solution for TCPINC > > I think there was significant consensus on the list that this is the case. > Another important consideration that was discussed in the list was about > deployability of the solution in particular the compatibility of a solution > with currently deployed middle-boxes. > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > 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. > > 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. > 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 > -- 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 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. > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
