Subject: [tcpinc] Protect or not the TCP header fields

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Oct 2014 19:01:53 +0200

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)

---

From: John Border <[email-masked]>
Date: Mon, 6 Oct 2014 13:21:35 -0400

Option 1.  Get passive eavesdropping protection deployed ASAP.  If better protection against TCP attacks is needed, it can be done separately as an enhancement without holding back what is needed now which is deployable passive eavesdropping protection.

John

-----Original Message-----
From: Tcpinc [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
Sent: Monday, October 06, 2014 1:02 PM
To: [email-masked]
Subject: [tcpinc] Protect or not the TCP header fields

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.

[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-masked]
https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Joe Touch <[email-masked]>
Date: Mon, 06 Oct 2014 11:34:35 -0700

> Port numbers: clearly we should not protect these.

FWIW, it's not clear whether protection might not be asymmetric, e.g.,
the server-side port is protected but not the client-side.

The list also omits the IP pseuduoheader fields, e.g., IP source and
destination addresses (the other fields, Reserved and Protocol, don't
seem to matter whether protected or not AFAICT).

For similar reasons, IMO it should be OK to protect the server IP address.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 06 Oct 2014 11:36:38 -0700

> Option 2.a -- include the MAC (and other relevant information) in a TCP

I don't think it's tenable to include TCP options or related information
in the payload (I made similar arguments about MPTCP control information
not being in-band).

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 6 Oct 2014 22:10:26 -0700

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-masked]>
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.
>
> 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).
>
> 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.
>
> We next describe some of the relevant considerations we identified and how
> they are impacted by the different choices.
>
> 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.
>
> 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).
>
> 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.
>
> deployability of the solution in particular the compatibility of a solution
> with currently deployed middle-boxes.
>
> 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 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.
> 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.
>
> 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.
>
> 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.
>
> 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.
> and taking one value from one segment for one field and taking a value from
> a different segment for the other one.
> options, but this can be done after we figure out if we should protect or
> not the TCP header.
>
> 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.
> 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.
>
> [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)
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 07 Oct 2014 07:28:08 +0200

Hi,
below...

> in the payload (I made similar arguments about MPTCP control information

could you provide the reasons for that? (I dont recall what was your 
argument back then)

Thanks, marcelo

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 6 Oct 2014 23:04:14 -0700

> - Protect only the payload (don't include any of the TCP header fields 

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...

> for the payload in the payload.

[...]

> makes sense to consider the protection the TCP fields independently.

This is an incorrect statement which you correct later about offset
sequence numbers...

> 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...

> 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"...

> 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...

> 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...

> 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...

> options, but this can be done after we figure out if we should protect 

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...

> This seems the option that provides higher deployability, lower security 

This IMO is a non-starter as replay attacks will be trivial in this
case...

> This option seems to provide lower deployability, higher security and 

Can you include information why you believe that this has lower
deployability?

> 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...

> that we can convey enough information in the TCP option to reconstruct 

This seems odd to have two MACs...  Though if the MAC option is getting
stripped, do we trust the connection?

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Oct 2014 02:14:16 -0400

> attack IMO should be done as it isn't that much more difficult...

You can protect replay attacks on the payload by incorporating a sequence
number into the integrity check. This is how TLS works ordinarily.

-Ekr

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 07 Oct 2014 08:19:45 +0200

El 07/10/14 08:04, John-Mark Gurney escribió:

> Can you include information why you believe that this has lower

see the text on the middleboxes that split and merge segments.
Including the MAC in an option would not work though these middleboxes.

David has made the argument that it would be possible to include some 
redundancy, so thjat if 1 of n MAcs actually make it to the destiantion 
it is the possible to verify the integrity. This however would break if 
the options get deleted too frequently. Overall, the deployability is 
lower that including the MAC in the payload (protecting of nor the TCP 
fields). Is this a big problem? well, that is the question we are posing 
to the WG...

Regards, marcelo

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 6 Oct 2014 23:32:29 -0700

> 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...

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...

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...

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..

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 6 Oct 2014 23:34:37 -0700

> fields). Is this a big problem? well, that is the question we are posing 

Per my reading of the research, it is such a minor problem that it
isn't one...  Most of the middleboxes that broke are broken in other
ways that they'll just revert to old normal TCP...

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 7 Oct 2014 09:32:14 +0000

> Option 1.  Get passive eavesdropping protection deployed ASAP.  If
> better protection against TCP attacks is needed, it can be done
> separately as an enhancement without holding back what is needed now
> which is deployable passive eavesdropping protection.

+1

Keep in mind the KISS principle

I think the TCP header is an orthogonal issue that can and should be solved separately. TCPM currently discusses hashing/MAC of headers/options fields for other purposes (e.g., middleboxes breaking EDO). If we need a MAC of header fields in TCP connections not using tcpinc, we should define *one* generic and modular solution for all TCP usage scenarios (on STD track) and not a tcpinc-specific MAC. Otherwise, I would be really concerned about interoperability between multiple TCP extensions calculating some form of MACs in their own way. In short, this looks to me like a separate RFC.

As a side note, this design choice really correlates with the question whether tcpinc runs an own framing in the payload.

Michael

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Oct 2014 16:20:14 +0300

> 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.

> 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).

> protocol was mentioned, nor was replay attacks in the last email,

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.

> 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-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 07 Oct 2014 10:39:04 -0700

> complexity of the protocol...

It means that TCP no longer becomes a segment-oriented protocol. Right
now, TCP receivers need touch user data only once - when it copies/moves
it into the socket buffer. Putting option context in-band (vs. in the
option space) means that you have interactions between retransmission
and reordering and the option protocol.

I.e., you end up potentially sending ACKs for segments received that you
would have dropped if you had checked their security context.

At that point, you open up a deep can of other vulnerabilities and
complexities.

Joe

---

From: Brandon Williams <[email-masked]>
Date: Mon, 13 Oct 2014 09:20:32 -0400

I prefer option 1 for the reasons that John and Michael state.

That said, if header integrity protection is the general consensus, I prefer

 > -- include the MAC for the TCP header fields in a TCP option and the
 > MAC for the payload in the payload

because I believe it can be made to work through a broader range of 
cooperative middle boxes than a solution that combines header and data 
integrity protection into a single MAC.

--Brandon

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Oct 2014 10:15:20 -0700

> I prefer option 1 for the reasons that John and Michael state.

My analysis of the header (which I can share) indicates that there is
very little value in protecting anything in the header (or
pseudoheader, which I note was not considered in the OP).

Acknowledgements are difficult, but if you consider the modes of
attack and the potential outcomes for an attacker, it isn't that
interesting.  An on-path attacker can (maybe) cause a sender to alter
their sending rate by falsifying or adjusting the acknowledgment
values.  But that reduces to a DoS attack at either extreme.  And most
on-path attackers have a greater capacity to do that anyway.

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Oct 2014 11:01:51 -0700

> Including the MAC in an option would not work though these middleboxes.

It might be useful to see Section 6.2 of draft-ietf-tcpm-tcp-edo-01.txt.

>From that:

   ...However, the most
   comprehensive study of these cases indicates that "although
   middleboxes do split and coalesce segments, none did so while
   passing unknown options" [Ho11].

   Middleboxes that silently remove options they do not implement have
   been observed [Ho11].

[Ho11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M.,
and H. Tokuda, "Is it still possible to extend TCP", Proc. ACM Sigcomm
Internet Measurement Conference (IMC), 2011, pp. 181-194.

I.e., any option-based solution might not work through a middlebox -
including the one that signals the use of TCPINC. At that point, we're
back to running TLS, and it seems pointless to discuss this as a TCP
variant, IMO.

Joe

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 13 Oct 2014 11:22:29 -0700

> back to running TLS, and it seems pointless to discuss this as a TCP

I agree with Joe. Can we list the attacks that would not be prevented by
TLS, but that would be prevented by a version of TCPINC that does not
protect the TCP header?

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Oct 2014 11:32:28 -0700

> TLS, but that would be prevented by a version of TCPINC that does not

I thought that seamless (i.e., opportunistic) negotiation of the
ability to run TLS was valuable, if nothing else.

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Oct 2014 11:34:17 -0700

> TLS, but that would be prevented by a version of TCPINC that does not

This discussing really needs consensus what middlebox behaviors should
be supported. IMO:

	YES:	NAT

		re-segmenting with option rewriting
		(shouldn't break connectivity at least,
		but might break protection)

	MAYBE:	segment rewriting with known option processing
		(should this keep protection or not?)

	NO:	segment rewriting with unknown option copying
		(no evidence this is more than hypothetical)

		unknown option removal (if so, we can't signal
		use of the option using TCP anyway)

I.e., if we're worried about whether protecting the header interferes
with the above, we ought to worry about whether it interferes with a
TCP-level solution, including use of the TCP option space to signal use
of TCPINC.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Oct 2014 11:37:40 -0700

> ability to run TLS was valuable, if nothing else.

TLS using unsigned (or self-signed) certs might be useful, but we've
been talking about a TCP-level solution so it wouldn't interfere with
userland TLS.

That requires TCP-level indication that TLS is being used. That requires
indicating the use of the additional layer of TLS somewhere - in the
port number, in a TCP option, etc. - but NOT in the data stream because
AFAICT we can't tell the difference between TCP-level TLS and userland TLS.

(FWIW, if we can, then we ought to be talking about this as a seamless
presentation layer and get "TCP" out of the discussion)

Joe

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Oct 2014 14:09:59 -0700

> AFAICT we can't tell the difference between TCP-level TLS and userland TLS.

That's not a huge problem.  An indication would be beneficial, or
perhaps more appropriately, a control knob to disable TCPINC.  That
would allow people to avoid having two layers of TLS, but at worst
it's merely suboptimal to have two layers.  I don't see there being
any fundamental problem with having two layers of protection.

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Oct 2014 14:14:54 -0700

> any fundamental problem with having two layers of protection.

The only real issue is:

	- if the indication is in the header option space,
	then it's susceptible to middleboxes that silently
	remove it

	- if the indication is in-band, it will be misinterpreted
	as data by legacy endpoints

	- if the endpoint looks for existing TLS at the beginning
	of a connection, then you could have a TCP server
	terminating user-level TLS at the client (interfering
	with user-level TLS at the server)

I.e., if this is a TCP level solution, it's either indicated by the
header or in-band.

My conclusion is that:

	- Once you use the header for an indicator,
	you might as well consider protecting at least
	some portions of it.

	- If you don't use the header as an indicator,
	you'll end up interfering with user-level TLS

Joe