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
