Subject: Re: [IPsec] New revision of TCP Encapsulation draft

From: Samy Touati <[email-masked]>
Date: Tue, 8 Dec 2015 06:40:11 +0000

Hi Yaron and Yoav,

An updated draft addressing your comments has been posted.

https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt

Please check it out, and provide feedback.

Thanks.
Samy.

From: Yaron Sheffer <[email-masked]>
Sent: Nov 20, 2015 3:11 PM
To: Tommy Pauly; IPsecME WG
Subject: Re: [IPsec] New revision of TCP Encapsulation draft

Hi Tommy,

I also think this is very relevant work. Here are some comments to -01:

I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited 
under "prior work", both because it is documented and also because I 
believe it is implemented by a vendor.

In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers 
will use UDP encapsulation even when there is no NAT on the path, for 
example because networks or middleboxes do not support IP protocols 
other than TCP and UDP."

"Although a stream" - this paragraph is not worded very well (streams 
don't send anything) and is hard to understand. There are lots of 
networks that use jumbo frames and so hardcoding the value 1500 into the 
spec may not be a good idea.

I can think of HA cases where several gateways are handling ESP SAs that 
are all associated with the same IKE SA. So I'm wondering why we are 
insisting on all Child SAs being in the same connection, and as a result 
requiring that an IKE message be the preamble to any new connection.

Although it might seem obvious, I think Sec. 3 should say explicitly 
that if the connection is closed midway through a message, the recipient 
must silently drop the partial message.

You may want to add to the last paragraph of the Security 
Considerations: This document explicitly does not define a profile for 
TLS when used in this manner, or any relation between identities at the 
IPsec level and those at the TLS level ("channel binding").

Thanks,
        Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:
> Hello,
>
> Based on the feedback received at our informal meeting in Yokohama, I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP:
>
> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01
>
> The revisions include:
> - More explanation in the introduction about the motivation, and other work that this draft is trying to standardize (3GPP recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL VPNs).
> - Comments about maximum IKE and ESP message size within the TCP stream, which is effective the MTU of the tunnel.
> - Specify that if the TCP connection is brought down and re-established, the first message on the stream must be an IKE message.
> - Detailed considerations about interactions with middleboxes (thanks Graham Bartlett for input on this).
>
> In the meeting in Yokohama, there was general agreement that this was relevant work that we’d like to keep looking into. Please read the document, and provide any feedback you have!
>
> Thanks,
> Tommy
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 8 Dec 2015 12:12:43 +0200

Hi Samy,

Thanks for the new draft. It addresses most of my comments, but one 
question remains.

I still don't understand why we require that each connection should 
start with an IKE message. The explanation given is "to allow the peer 
to know with which IKE session the traffic is associated." But of course 
the ESP SPI identifies the Child SA, and implicitly, the IKE SA.

Moreover, later in the same section you allow multiple IKE SAs over the 
same connection, which again doesn't work well with the reasoning above.

Best,
     Yaron

On 12/08/2015 08:40 AM, Samy Touati wrote:
> *From:* Yaron Sheffer <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Nov 20, 2015 3:11 PM
> *To:* Tommy Pauly; IPsecME WG
> *Subject:* Re: [IPsec] New revision of TCP Encapsulation draft
>
> Hi Tommy,
>
> > Based on the feedback received at our informal meeting in Yokohama, 
> I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP:
> >
> > - More explanation in the introduction about the motivation, and 
> other work that this draft is trying to standardize (3GPP 
> recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL VPNs).
> > - Comments about maximum IKE and ESP message size within the TCP 
> stream, which is effective the MTU of the tunnel.
> > - Specify that if the TCP connection is brought down and 
> re-established, the first message on the stream must be an IKE message.
> > - Detailed considerations about interactions with middleboxes 
> (thanks Graham Bartlett for input on this).
> >
> > In the meeting in Yokohama, there was general agreement that this 
> was relevant work that we’d like to keep looking into. Please read the 
> document, and provide any feedback you have!
> >
> > Thanks,
> > Tommy
> > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 08 Dec 2015 12:24:21 -0800

Hi Yaron,

The original version of the draft did not require that the new TCP connection begin with an IKE message, but it was added in response to feedback we received at our meeting in Yokohama.

The concern was that the new TCP connection would almost certainly have different ports from the old connection. In order for the server to send packets back to the client, it needs to know the correct mapping for both the IKE SAs and the Child SAs. If we allow an ESP packet to be the first packet of a new connection, it may be hard to implement a correct server that reacts to that and adjusts all associated IKE and Child SA values to use the new port. However, it the first packet is an IKE packet, the server can essentially treat it as if it were MOBIKE and reset the ports.

In the case of multiple IKE SAs over a TCP connection (which is a new edge case that has been brought up), perhaps it would make sense to say that for all IKE SAs using the connection, at least one IKE message must precede any ESP messages for a Child SA of the IKE SA.

Does this make sense?

Thanks,
Tommy

> On Dec 8, 2015, at 2:12 AM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi Samy,
> 
> Thanks for the new draft. It addresses most of my comments, but one question remains.
> 
> I still don't understand why we require that each connection should start with an IKE message. The explanation given is "to allow the peer to know with which IKE session the traffic is associated." But of course the ESP SPI identifies the Child SA, and implicitly, the IKE SA.
> 
> Moreover, later in the same section you allow multiple IKE SAs over the same connection, which again doesn't work well with the reasoning above.
> 
> Best,
>     Yaron
> 
>> https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt <https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt>
>> 
>> From: Yaron Sheffer < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>
>> > https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01 <https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01>
>> >
>> > The revisions include:
>> > https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>> >
>> 
>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 8 Dec 2015 23:08:25 +0200

Hi Tommy,

Thanks for clarifying this point. But I still think we are making a 
protocol change for what can be solved easily at the implementation 
level. Implementations will need to tag each IKE SA with the currently 
valid TCP connection on which responses can be sent. And ESP SAs likely 
already point to their parent IKE SA. So when we have an ESP packet that 
needs to be sent back from the responder, why not look up its associated 
IKE SA and use it to find the TCP connection?

IMHO it would be better if we can stick to the simple model of a TCP 
wrapper for an unordered pile of IKE and ESP messages. This would add 
TCP with the minimal change to ESP, IKE and the relationship between them.

Thanks,
     Yaron

On 12/08/2015 10:24 PM, Tommy Pauly wrote:
> Hi Yaron,
>
> The original version of the draft did not require that the new TCP 
> connection begin with an IKE message, but it was added in response to 
> feedback we received at our meeting in Yokohama.
>
> The concern was that the new TCP connection would almost certainly 
> have different ports from the old connection. In order for the server 
> to send packets back to the client, it needs to know the correct 
> mapping for both the IKE SAs and the Child SAs. If we allow an ESP 
> packet to be the first packet of a new connection, it may be hard to 
> implement a correct server that reacts to that and adjusts all 
> associated IKE and Child SA values to use the new port. However, it 
> the first packet is an IKE packet, the server can essentially treat it 
> as if it were MOBIKE and reset the ports.
>
> In the case of multiple IKE SAs over a TCP connection (which is a new 
> edge case that has been brought up), perhaps it would make sense to 
> say that for all IKE SAs using the connection, at least one IKE 
> message must precede any ESP messages for a Child SA of the IKE SA.
>
> Does this make sense?
>
> Thanks,
> Tommy
>
>> On Dec 8, 2015, at 2:12 AM, Yaron Sheffer <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Samy,
>>
>> start with an IKE message. The explanation given is "to allow the 
>> peer to know with which IKE session the traffic is associated." But 
>> of course the ESP SPI identifies the Child SA, and implicitly, the 
>> IKE SA.
>>
>> Moreover, later in the same section you allow multiple IKE SAs over 
>> the same connection, which again doesn't work well with the reasoning 
>> above.
>>
>> Best,
>>     Yaron
>>
>>> *From:* Yaron Sheffer <[email-masked]>
>>> > Based on the feedback received at our informal meeting in 
>>> Yokohama, I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP:
>>> >
>>> was relevant work that we’d like to keep looking into. Please read 
>>> the document, and provide any feedback you have!
>>> >
>>> > Thanks,
>>> > Tommy

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 14 Dec 2015 17:46:07 +0300

Hi,

I have some comments on the TCP Encapsulation draft.

1. The draft assumes that using TCP encapsulation is always pre-configured,
    i.e. for each peer there is a configuration option with two possible values - 
    either "use traditional UDP transport" or "use TCP (TLS) transport".
    I think that this is inflexible since network topology can change over time
    as well as middleboxes' capabilities. Since TCP encapsulation is 
    a "last resort" with a lot of drawbacks, I'd rather make it use only when 
    it is really needed. Granted the use of TCP encapsulation
    cannot be negotiated, however the case when it is needed can be detected.
    So, I suggest to add the third option - "try first UDP transport and fall back
    to TCP (TLS) encapsulation if no response was received". Note, that this behaviour
    is already defined in the draft when peer's addresses are changed via MOBIKE, 
    I just suggest to make it available from the beginning of SA establishment.    

2. Please, emphasize that TCP encapsulation cannot replace traditional
    transport, otherwise we can run into interoperability problem. 
    Something along the lines:

        Those implementations that support TCP encapsulation MUST still support 
        traditional transport, defined in [RFC7296] for IKE and in [RFC4303] and
        [RFC3948] for ESP.

3. The following text in Section 3 is unclear to me:

       Although a TCP stream may be able to send very long messages,
       implementations SHOULD limit message lengths to typical UDP datagram
       ESP payload lengths.  

    I wonder what is a "typical UDP datagram ESP payload lengths"?
    How implementation could limit upper-level's message length? 

4. The draft is silent about AH. I presume AH cannot be used with 
    TCP encapsulation (as it cannot be used with UDP encapsulation),
    however I think it must be spelled out.

5. For the following text:

       An unexpected FIN or a RST on the TCP connection may indicate either
       a loss of connectivity, an attack, or some other error. ... The original
       initiator (that is, the endpoint that initiated the TCP connection
       and sent the first IKE_SA_INIT message) is responsible for re-
       establishing the TCP connection if it is torn down for any unexpected
       reason. 

    I think this is not enough. Consider the situation when attacker manages to
    send RST to only one peer, say it be the original responder. In this case
    the states of the peers become de-syncronized: while the original responder
    tearns down its TCP session, the original initiator thinks it is up.
    If the original responder has some data to be sent while the original 
    initiator has no such data, then we have some kind of deadlock.
    It seems that the original initiator must send keepalive messages
    with a pretty high frequency whenever it becomes idle.

6. Section 5 allows presence of multiple TCP connections for a single IKE SA,
    however this is allowed for some corner cases. It is my impression, that
    in most cases there will be one TCP connection per IKE SA. 
    If it is the case, then some clarification should be added how
    situations when peer temporarily has more TCP commections per
    IKE SA are resolved. Consider the example from the comment above, but
    when RST is sent only to the original initiator. In this case the initiator
    restores TCP connection, that leads to an existence of 2 TCP
    connections on the original responder - the old, which is defunct,
    but the responder thinks it's up, and the newly created. 
    Which connection the responder should use? It seems that
    some clarification should be added along the lines:

        If an IKE endpoint receives cryptographically protected 
        message on a new TCP connection, that is different 
        from the TCP connection associated with the IKE/ESP
        SA the message was received over, the endpoint MUST
        tear down existing TCP connection and MUST use the new
        one for their outgoing traffic.

    I'm not sure this text alignes witth the allowance to have
    multiple TCP connections per SA, though...

7. I think it's worth to clarify that with TCP encapsulation the IKE SA
    establishment starts using port 4500 from the very beginning, 
    so no port switching from 500 to 4500 takes place.

8. In my opinion Section 8 is a mess. It mixes up all kinds of
    keepalive-like messages used for different purposes. 

    First, I don't think NAT keepalive messages are needed
    for TCP encapsulation. As far as I know NAT boxes keep track
    of TCP state and keep mapping until TCP is torn down
    (unlike UDP where no explicit indication of session state exists
    and therefore it is only determided by existence of traffic).
    Disclaimer: I'm not an expert in modern NATs and probably
    things get changed and I'm wrong. In this case the TCP encapsulation 
    of NAT keepalive  messages must be described in the document,
    since they are neither IKE nor ESP messages.
    
    Then, there is no such thing as "TCP NAT keepalives". 
    The referenced RFC1122 describes TCP keep-alives (no "NAT"!)
    and their sole purpose is to allow server to clear up stale
    TCP connections when clients reboot. RFC1122 never suggested
    to use them as NAT keepalives (note the recommended default 
    interval for them - no less than 2 hours!). Disclaimer: again,
    I'm not an expert in modern TCP trends, but if currently TCP
    keep-alives are used differently, then appropriate source
    should be referenced.

    I'm not familiar with TLS keepalives, but I'd rather let TLS
    along and let it use its mechanisms as specified in TLS RFC,
    without imposing additional requirements in this document.

    Conclusion: among the listed only the IKE check liveness messages
    are relevant to TCP encapsulation. But their usage in this case 
    should be clarified (see my comment #5).

9. Please, add text that some of IKEv2 (and its extensions) mechanisms
    become useless with TCP encapsulation and MUST NOT (SHOULD NOT?)
    be used. In particular - cookie has a little value with TCP since it is no longer 
    allows responder to remain stateless. Moreover, TCP handshake determines
    peer IP address and protects to some extend from spoofing (I assume ISN
    is unpredictable as it should be). Another thing that becomes useless is 
    sending NAT keepalive messages (but see previous comment). 
    And IKEv2 extension that becomes useless with TCP encapsulation is 
    IKEv2 fragmentation.

Regards,
Valery Smyslov.

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 14 Dec 2015 16:29:28 -0800

> On Dec 14, 2015, at 6:46 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi,

Hi Valery,

Thanks for your comments! Responses inline.
>   i.e. for each peer there is a configuration option with two possible values -    either "use traditional UDP transport" or "use TCP (TLS) transport".
>   as well as middleboxes' capabilities. Since TCP encapsulation is    a "last resort" with a lot of drawbacks, I'd rather make it use only when    it is really needed. Granted the use of TCP encapsulation
>   is already defined in the draft when peer's addresses are changed via MOBIKE,    I just suggest to make it available from the beginning of SA establishment.    

The idea of using TCP as the fallback from UDP is exactly what the entire draft is about. The preconfiguration is not whether to always use TCP, but whether to use TCP once UDP fails, and upon which port. Since the entire idea of using TCP is predicated on the idea that UDP was already blocked on a previous attempt, this must be preconfigured.

TCP is only used when UDP fails:
"If both of the other two methods are not
         available or appropriate, both IKEv2 negotiation packets as
         well as ESP packets can be sent over a single TCP connection to
         the peer."

As it says in the configuration section, UDP is the preferred transport: 

"Since TCP encapsulation of IKEv2 and IPSec packets adds overhead and
   has potential performance trade-offs compared to direct or UDP-
   encapsulated tunnels (as described in Performance Considerations, Section 7), 
implementations SHOULD prefer IKEv2 negotiation over UDP.”

We can make it more explicit that UDP should be tried first, but that is certainly the intent.

>   transport, otherwise we can run into interoperability problem.    Something along the lines:
> 
>       Those implementations that support TCP encapsulation MUST still support        traditional transport, defined in [RFC7296] for IKE and in [RFC4303] and
>       [RFC3948] for ESP.

Sure, although I think clarifying (1) that UDP is always tried first should cover this as well.

>   How implementation could limit upper-level's message length? 

Based on discussion on the list, we decided not to specify a specific value. The point is to not send very large messages in the TCP stream, since they will often be sent back into a traditional unix networking kernel once decrypted. The message length can be simply limited by setting the MTU to a normal value on the virtual interface being used for the VPN.

> 4. The draft is silent about AH. I presume AH cannot be used with    TCP encapsulation (as it cannot be used with UDP encapsulation),

Okay, we can say this only applies to ESP, not AH.
>   If the original responder has some data to be sent while the original    initiator has no such data, then we have some kind of deadlock.

RST attacks are inherent to TCP. What do you propose on top of this? I don’t think we want to recommend for more frequent keepalives, necessarily. Note that any time the client will try to send any traffic (this is any ESP traffic, so it will probably be fairly quickly), the connection will get a RST if the server thinks the port is no longer open.

>   in most cases there will be one TCP connection per IKE SA.    If it is the case, then some clarification should be added how
>   but the responder thinks it's up, and the newly created.    Which connection the responder should use? It seems that
>       If an IKE endpoint receives cryptographically protected        message on a new TCP connection, that is different        from the TCP connection associated with the IKE/ESP
>   multiple TCP connections per SA, though…

I think that recommendation makes sense. We’ll work on it and add to the next version.

>   establishment starts using port 4500 from the very beginning,    so no port switching from 500 to 4500 takes place.

It’s not necessarily port 4500 at all! In fact, it will likely not be. But that is true that port switching does not take place. We can add a line to re-iterate that.

>   things get changed and I'm wrong. In this case the TCP encapsulation    of NAT keepalive  messages must be described in the document,
>      Then, there is no such thing as "TCP NAT keepalives".    The referenced RFC1122 describes TCP keep-alives (no "NAT"!)
>   to use them as NAT keepalives (note the recommended default    interval for them - no less than 2 hours!). Disclaimer: again,
>   are relevant to TCP encapsulation. But their usage in this case    should be clarified (see my comment #5).

I disagree that the other keep alive types are not relevant. This section is simply a list of "mechanisms [that] may be employed” for keepalives, and it is useful for an implementer to know which keep alive mechanisms may be taking place on their connection. It is very important that TCP encapsulation can be implemented as a layer transparent to existing TCP, TLS, and ESP implementations. By default, these layers may have keepalives of their own. The ESP implementation in a kernel may not know that the traffic will be sent over a TCP flow, and if MOBIKE is being used, it may switch between UDP and TCP on different networks. Therefore, we should not recommend that NAT keepalives be disabled.

We can remove the spurious “NAT” qualifier from the TCP keepalives.

>   be used. In particular - cookie has a little value with TCP since it is no longer    allows responder to remain stateless. Moreover, TCP handshake determines
>   is unpredictable as it should be). Another thing that becomes useless is    sending NAT keepalive messages (but see previous comment).    And IKEv2 extension that becomes useless with TCP encapsulation is    IKEv2 fragmentation.

I do not think we should recommend that any of these extensions MUST NOT be used, specifically since TCP encapsulation is something done as fallback for connections in which UDP is blocked, and in the case of MOBIKE, may be used on a connection that uses UDP on other networks.
- Cookies: the TCP connection here should not be considered ‘state’ from the perspective of IKE. The TCP connection is independent of the IKE sessions. It still may be useful to keep the cookie mechanism.
- We already address NAT keepalives: "If TCP keep-alives are used, IPSec ESP NAT keep-alives may be considered redundant and can safely be disabled.”
- Fragmentation is still useful, depending on the implementation. One way of implementing is by taking the TCP messages, re-encapsulating them as traditional UDP, and forwarding them onto a legacy stack. There is also the consideration of MOBIKE—we want to negotiate fragmentation support in case we switch back to a network that supports UDP!

Thanks for your time looking at this!
Tommy

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 15 Dec 2015 11:16:18 +0300

Hi Tommy,

thank you for the answers. See my comments inline.

> The idea of using TCP as the fallback from UDP is exactly what the entire draft is about.
> The preconfiguration is not whether to always use TCP, but whether to use TCP once
> UDP fails, and upon which port. Since the entire idea of using TCP is predicated on the
> idea that UDP was already blocked on a previous attempt, this must be preconfigured.
>

Yes, please. The current text is not very explicit about that, at least in me reading.

> Sure, although I think clarifying (1) that UDP is always tried first should cover this as well.

Agree.

> Based on discussion on the list, we decided not to specify a specific value. The point is to not send very
> large messages in the TCP stream, since they will often be sent back into a traditional unix
> networking kernel once decrypted. The message length can be simply limited by setting the
> MTU to a normal value on the virtual interface being used for the VPN.

I think it would be benefitical for implemeters if you clarify this giving them some
concrete guidelines.

> RST attacks are inherent to TCP. What do you propose on top of this? I don’t think we want
> to recommend for more frequent keepalives, necessarily. Note that any time the client will
> try to send any traffic (this is any ESP traffic, so it will probably be fairly quickly),
> the connection will get a RST if the server thinks the port is no longer open.

The situation described above is quite real. Suppose the client is downloading a large file
from the server. In this case the server always has data to be sent, while the client
only responses with ACKs. If the client receives no new data it just waits. Of course
if it has something to send, the TCP connection will be restored. That's why
it is probably worth to send liveness check messages from the initiator to the responder
if there is no incoming traffic for some period of time (say 10-20 seconds)
and the endpoint has no data to send to the peer.

Note, that it is a bit different from how liveness check messages are supposed
to be used in IKEv2, where liveness check should be done if there is no incoming
traffic for some period of time AND if the endpoint is about to send new data to the peer.

> It’s not necessarily port 4500 at all! In fact, it will likely not be. But that is true that port switching does not 
> take place. We can add a line to re-iterate that.

Oh, I see that the port is not necessary 4500. However I think
the clarification that no port switching takes place would be useful.

> I disagree that the other keep alive types are not relevant. This section is simply a list
> of "mechanisms [that] may be employed” for keepalives, and it is useful for an implementer
> to know which keep alive mechanisms may be taking place on their connection.

>From my naive :-) literal reading the section lists the keepalive methods that are available
for the implementation to choose from:

   It is up to the implementation to decide which keepalives are
   appropriate for TCP-encapsulated connections.

So, I read that as the implementations should be aware of all these methods and
use an appropriate one. But this reading differs from your clarification below:

> It is very important
> that TCP encapsulation can be implemented as a layer transparent to existing TCP, TLS, and ESP
> implementations. By default, these layers may have keepalives of their own.

I agree that layer separation is important, so the only available keepalives
for the IPsec layer are NAT keepalives and liveness check messages.
The other methods are irrelevant here. An implementation can be aware
of their an existance, but usually cannot control them. I think it must be clarified.

> The ESP implementation
> in a kernel may not know that the traffic will be sent over a TCP flow, and if MOBIKE is being used,
> it may switch between UDP and TCP on different networks. Therefore, we should not recommend
> that NAT keepalives be disabled.

Well, I think that IPsec level must always know what encapsulation is currently
active and use NAT keepalives only when UDP encapsulation takes place.
For example, it doesn't send NAT keepalives if "direct" encapsulation is used.

In any case, if for the purposes of simplicity the draft allowed an implementation
to send NAT keepalives in case of TCP encapsulation, then their layout and
processing should have been described (a la Sections 3.1 and 3.2).
And in this case the text from Section 3:

   In order to encapsulate IKEv2 and ESP messages within a stream (which
   may be raw TCP, or TLS over TCP), a 32-bit length field precedes
   every message.  If the first 32-bits of the message are zeros (a Non-
   ESP Marker), then the contents comprise an IKEv2 message.  Otherwise,
   the contents comprise an ESP message.

is not correct, since NAT keepalives are neigther IKE nor ESP messages.

> We can remove the spurious “NAT” qualifier from the TCP keepalives.

OK.

> I do not think we should recommend that any of these extensions MUST NOT be used,

Note, that I've also included "SHOULD NOT" as an alternative since MUST NOT is probably too strong.

> specifically since TCP encapsulation is something done as fallback for connections in which
> UDP is blocked, and in the case of MOBIKE, may be used on a connection that uses UDP
> on other networks.
> - Cookies: the TCP connection here should not be considered ‘state’ from the perspective of IKE.
> The TCP connection is independent of the IKE sessions. It still may be useful to keep the cookie mechanism.

Well, I see the only useful application for the cookie in case of TCP encapsulation -
if puzzle mechanism is adopted then the cookie must be used even in this case.

> - We already address NAT keepalives: "If TCP keep-alives are used, IPSec ESP NAT keep-alives may be
> considered redundant and can safely be disabled.”
> - Fragmentation is still useful, depending on the implementation. One way of implementing is by taking
> the TCP messages, re-encapsulating them as traditional UDP, and forwarding them onto a legacy stack.
> There is also the consideration of MOBIKE—we want to negotiate fragmentation support in case we
> switch back to a network that supports UDP!

I think that all the mechanisms that seem to become unnecessary with TCP encapsulation
must be separately discussed in the document. There must be some text describing under which
circumstances these mechanisms are still useful and when it is safe to abandon them. I don't insist
on MUST NOT (or SHOULD NOT), but some guidlines must be given, otherwise
implementers will wonder: why should we spent resources doing useless things.

Thank you,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Dec 2015 10:05:31 -0500 (EST)

> and the endpoint has no data to send to the peer.

Applications already need to deal with silent remote parties? It
does not depend on ESPinTCP. So I find this example not very convincing.

However, NAT gateways do time out TCP connections, so if the IPsec SA is
genuinely idle, we might need to send something to keep it alive. But
then sending a liveness probe is fine for that.

> traffic for some period of time AND if the endpoint is about to send new data 

That's not my understanding of livenss. What we do is time based
liveness probes that are skipped when we detected there was recent
traffic on the IPsec SA.

> the clarification that no port switching takes place would be useful.

When an RST happens, you do come back and if behind NAT you most likely
will come back on a different port. So be caerful with using terms as
port switching. (I wish we could get rid of that anyway, are there still
any ipsec passthrough devices in use mangling port 500? or is there any
reason why not to always start on 4500?)

> of their an existance, but usually cannot control them. I think it must be 

Something along the lines of "Since the goal is to move back to UDP as
soon as possible, most properties of the IKE connection that only make
sense on UDP should still be kept for TCP".

> And in this case the text from Section 3:

NAT keepalives and ESPinTCP packets have the same property of needing to
take packets from the TCP stream and not send them to userland. I'm not
sure if that's easy to do. Does an application need to see any lowlevel
TCP stuff like sequence numbers? Or can it just do a read() and not
worry? If this is transparent to the userland, eg it wont see the NAT
keepalives, then we might as well just allow them simiarly to UDP.

Although with DPD/liveness, it makes more sense to never use NAT
keepalives as the latter only keeps the mapping open but you don't
know if there is still anyone at the other end.

> is not correct, since NAT keepalives are neigther IKE nor ESP messages.

Oh, if we allow this inside a TLS stream, then I guess NAT keepalives
cannot be eaten by the kernel, so I would recommend not using them and
use a liveness probe instead.

> implementers will wonder: why should we spent resources doing useless things.

Isn't it more the other way around? When we cannot use these things we
need new code to track when NOT to do things. Still I agree we need
to guide implementors properly.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 15 Dec 2015 18:50:06 +0300

Hi Paul,

> does not depend on ESPinTCP. So I find this example not very convincing.

I don't care about applications, I care about IPsec implementations :-)
Currently an IPsec implementation can always send out a ESP packet
if ESP SA is up. With TCP encapsulation there may be situations
when ESP SA is up, however the encrypted packet cannot be 
send out because there is no TCP session associated with this 
ESP SA. What IPsec implementation is supposed to do with the data
that TCP/IP stack is trying to send out? Discard? Collect in a hope
that TCP is restored quickly?

> then sending a liveness probe is fine for that.

Are you saying that if I open telnet session via NAT and then
go for dinner, that the session will be broken when I return?

Well, I agree that NAT and firewalls can drop any TCP session
at their will, but do they do it regularly in case of timeout?
And what is the typical timeout timeout for TCP?

> liveness probes that are skipped when we detected there was recent

RFC7296 is not very explicit about that. Please see RFC3706 (DPD)
Section 5.5, that contains more speculations on this:

   Since the liveliness of a peer is only questionable when no traffic
   is exchanged, a viable implementation might begin by monitoring
   idleness.  Along these lines, a peer's liveliness is only important
   when there is outbound traffic to be sent.  To this end, an
   implementation can initiate a DPD exchange (i.e., send an R-U-THERE
   message) when there has been some period of idleness, followed by the
   desire to send outbound traffic.  

Compare with RFC7296, Section 2.4:

   If no
   cryptographically protected messages have been received on an IKE SA
   or any of its Child SAs recently, the system needs to perform a
   liveness check in order to prevent sending messages to a dead peer.

Here - if you don't want to send message to a peer, you don't care if
it is dead, do you?

> port switching. 

Agree.

> (I wish we could get rid of that anyway, are there still

You can. It is explicitely allowed by RFC7296.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Dec 2015 11:04:31 -0500 (EST)

On Tue, 15 Dec 2015, Valery Smyslov wrote:

> when ESP SA is up, however the encrypted packet cannot be send out because 
> there is no TCP session associated with this ESP SA. What IPsec 
> implementation is supposed to do with the data

I think the subsystem should "send" it, whether it gets dropped or
queued up for a new TCP session would be up to the implementation?

> go for dinner, that the session will be broken when I return?

Yes, since about 1997 :)
If you did not realise that you spend too much time on IETF networks :)

> And what is the typical timeout timeout for TCP?

Yes. around 15-20 minutes if you are on stable (non-coffee, not-hotel) NATworks.

>   when there is outbound traffic to be sent.

That I disagree with. I want to cleanup roadwarriors who have left at
some point, which means a liveness probe without me having traffic
pending for them.

>  To this end, an

I guess it assumes the other end acts the same, so if any endpoint wants
to send, they will do liveness. But I agree the RFC text could be
better.

> You can. It is explicitely allowed by RFC7296.

I know. But I still can't do that :) I'm not even sure if most IKEv2
implementations can run fine without port 500. Also I would have
prefered to get rick of 4500, not 500, which is not what 7296 allows.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 16 Dec 2015 09:20:04 +0300

> some point, which means a liveness probe without me having traffic

Definitely you can do it. It's a usual tradeoff between wasting 
resources doing frequent liveness checks and wasting memory
for the dead connection. Choose right balance.

> to send, they will do liveness. 

Sure. The problem is that with TCP encapsulation the other end may have
no TCP session and would have been unable to send any traffic (including
liveness checks) until this end (the original initiator) restores TCP seesion.

Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Dec 2015 14:53:17 +0200

> reason why not to always start on 4500?)

Has there ever been devices doing something special for TCP traffic on
port 500? I think most of the issues has been with UDP traffic, where
the both source and destination ports were specified to be 500, so
some NAT devices decided, that because of that we cannot NAT the
source port, thus we need to do something special for IPsec traffic.
The port 4500 was just getting rid of this helpful thing NAT boxes
tried to do.

With TCP encapsulated IPsec, the source port will most likely be
random port anyways, and the destination port will be either 500 or
4500. I would actually say we should use TCP port 500 for servers
always and not use port 4500 at all.

And the source TCP port will most likely be different even if there is
no NAT between, for example when using IPv6 and going through firewall
which is configured to drop all UDP traffic (and which might do some
special cases for DNS). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Dec 2015 15:08:46 +0200

> that TCP is restored quickly?

Most likely the smart thing is to drop it immediately. It is exactly
same thing than when your ESP packets do not go through as network is
broken somewhere in the middle.

There is no point of queuing them up, as upper layer protocols will
retransmit those packets and then the queue will fill up with
retransmissions etc, and the upper layer protocols are expecting more
about dropped packets, than packets delayed by tens of seconds. 

> go for dinner, that the session will be broken when I return?

Yes.

Just last week I was in some meeting room network, which teared down
my ssh connections every few minutes. I kept hitting enter on my shell
windows every now and then, and usually some of them got disconnected.
The stupid NAT box didn't even send RST, thus my connections just hang
for several minutes waiting for the TCP timeouts.

As this didn't seem to be consistent with activity, i.e it could
happen even when I was using the connection, we assumed the NAT box
was running out of memory or something and cleaning up TCP connections
at random... 

> And what is the typical timeout timeout for TCP?

If the NAT boxes have timeout for TCP sessions it is quite long
(minutes, tens of minutes, or hours), but if they run out of memory
they can clear state quite quickly. 

> > liveness probes that are skipped when we detected there was recent

There is no point of sending periodic liveness checks ever. Liveness
checks are supposed to be used when you suspect that other end is no
longer alive, and if you get reply back you do know it is alive.

> Here - if you don't want to send message to a peer, you don't care if

Yes.

The idea is that you want to avoid black hole, i.e. you are sending
stuff, and other end is dropping it because state got cleared from the
other end.

I.e. you are supposed to do liveness check when you for example
receive some kind of ICMP which would indicate that other end might be
down (for example port unreachable, host unreachable etc).

Also other end is sending traffic to you and you are sending traffic
to him, but then suddenly the other end stops sending traffic to you,
i.e. the traffic pattern changed to be unidirectional. This could of
course be because traffic changed, but it could indicate there is
problem. So when you detect that (i.e. you are sending traffic, but
other end is not sending any cryptographically protected messages),
you do liveness check. If the other end respondes you know it is
alive, and traffic pattern simply changed. If the traffic pattern
stays one way for longer time, you might repeat the liveness check at
some point, as otherwise you do not detect whether the other end died
or not.

In normal case one way traffic patters are not very common, so you
always have traffic coming back (ACKs etc).

There is stupid implementations out there which do send liveness
checks every n seconds regardless of anything else, but those are just
bad implementations.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Dec 2015 15:17:55 +0200

> some point, which means a liveness probe without me having traffic

Why? Doing liveness probe is much more expensive operation than
keeping IKE SA and Child SAs in memory. If the connection is silent,
there is no traffic thus there is no cost unless you run out of
memory. When you are starting to run out of memory you can do liveness
checks to clear out dead connections.

You can also just set the rekey interval to be 3600 seconds or
something, and then that rekey will do "liveness" check for you :-)

> to send, they will do liveness.

Of course both ends acts the same. This text is not tied to any one
end. 

> But I agree the RFC text could be better.

I think the current text is fine. It could also say that "you MUST NOT
do periodic liveness checks", but I assume some people would have
objected to that, just because that would made their implementations
non-conforming...
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 17 Dec 2015 16:44:47 +0300

Hi Tero, 

> checks every n seconds regardless of anything else, but those are just

My point was that with TCP encapsulation this "stupid" behaviour
wil probably become the "standard" one. Otherwise there is
a chance running into the situation when the original responder loses
TCP session (e.g. RST from an attacker), while the original Initiator
thinks the TCP session is still up. In this case if the Initiator
has nothing to send to the responder, it will remain silent,
while the responder will be unable to use the SAs.
The situation will last until the initiator sends something to the responder:
the responder sends back RST (as it doesn't have this TCP session)
and then the initiator creates a new TCP session. 

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Dec 2015 16:36:13 +0200

> and then the initiator creates a new TCP session. 

This is exactly what happens when you using NAT-T in normal case too.
I.e. if the responder looses state, it cannot do anything until
initiator reconnects.

Btw, if you have integrated TCP encapsulated IPsec you can also act on
the TCP RST by trying to do liveness check inside the TCP. If that
fails then you tear down the TCP session, if it works, then you simply
ignore the RST, as it was clearly an attack as other end is still has
TCP session up and running.

This of course requires kernel to know which TCP sessions are used for
the IPsec, and instead of tearing the TCP sessions down they need to
indicate the RST to the IPsec so IPsec can check things before telling
whether the TCP session needs to be taken down.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 17 Dec 2015 18:35:12 +0300

> I.e. if the responder looses state, it cannot do anything until

What do you mean by state here? SA? It is not so easy for attacker
to force responder loose its SA. If the responder is rebooted than
it probably looses all the upper level connections with the initiator
and has nothing to send.

On the other hand, such situation may appear if NAT in between
deletes its mapping. The NAT keepalives messages from the initiator
will quickly create a new one, however the responder won't use
new ports until it receives a cryptographically protected message
from the initiator. This situation is similar to what I described.