Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Mon, 14 Nov 2016 13:21:31 +0000

Two comments:

1. The draft seems to imply that only tunnel initiator is allowed to initiate TCP session,  however what is behavior after TCP connection is lost and initiator need to re-create it? does it do it right away or only re-create TCP session when initiator need to send some packet? I assume it should be right away, because otherwise there will be traffic loss if the responder need to send packet before the TCP session is re-created;
So if my above understanding is correct, I'd like draft to clearly state the behavior; 

2. section 6 mention that implementation should be able to receive from any TCP session and not enforcing any strict mapping; that's fine for receiving, however for sending traffic, system (specially responder) still  need to know which TCP session to use to reach peer of a given SA; for example, If NAT is detected, then in case of TCP session is lost on initiator side but still exists on responder side and initiator re-create the TCP session, the new TCP session might have a different NAT public port or even different NAT public address, so the responder can't tell if the new TCP session is for an existing SA or a new tunnel, this means initiator need to send message for all existing SA that need to use the new TCP session so that responder could update its SA-to-TCP session mapping because otherwise responder might use the old TCP session for outgoing traffic of existing SA and traffic will be blackholed; in section 6, draft states that either UPDATE_SA_ADDRESS or a IKE keepalive could be used, however there is no specification of behavior for updating CHILD_SA mapping when MOBIKE is not supported;  maybe initiator should send some kind of dummy packet over the CHILD_SA to update responder's mapping?

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Tommy Pauly
> Sent: Monday, October 31, 2016 9:01 AM
> To: IPsecME WG
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt
> 
> Hello,
> 
> I’ve posted a new version of the TCP encapsulation draft with the following
> changes:
> 
> 1. Added a section to explicitly discuss how to fallback from UDP to TCP
> (retransmissions, etc) based on feedback from the charter discussion 2.
> Explained that this method of encapsulation can be used for any stream
> protocol, and is not TCP specific, based on feedback from the charter
> discussion 3. Clarified the use of multiple TCP connections for Child SAs,
> based on Jun Hu’s questions
> 
> Also, I’m happy to say that we’ve been doing interoperability testing between
> Apple clients and Cisco server for TCP encapsulation. If anyone else has an
> implementation they’d like to try out, please let us know!
> 
> Best,
> Tommy
> 
> > On Oct 31, 2016, at 8:56 AM, [email-masked] wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the IP Security Maintenance and Extensions of
> the IETF.
> >
> >        Title           : TCP Encapsulation of IKE and IPsec Packets
> >        Authors         : Tommy Pauly
> >                          Samy Touati
> >                          Ravi Mantha
> > 	Filename        : draft-ietf-ipsecme-tcp-encaps-03.txt
> > 	Pages           : 20
> > 	Date            : 2016-10-31
> >
> > Abstract:
> >   This document describes a method to transport IKE and IPsec packets
> >   over a TCP connection for traversing network middleboxes that may
> >   block IKE negotiation over UDP.  This method, referred to as TCP
> >   encapsulation, involves sending both IKE packets for tunnel
> >   establishment as well as tunneled packets using ESP over a TCP
> >   connection.  This method is intended to be used as a fallback option
> >   when IKE cannot be negotiated over UDP.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-03
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > 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: Valery Smyslov <[email-masked]>
Date: Tue, 15 Nov 2016 06:36:23 +0900

Hi Jun,

for the second part:  your IKE SA must be linked to all child SAs
it created (in other words, child SAs must remember which IKE SA
created them and visa versa, otherwise a lot of IKEv2 logic
doesn’t work). So there is no need to send packets over all
child SAs, it’s enough to send liveness check over IKE SA,
so that responder learn new TCP-IKE mapping and use it 
for linked child SAs as well. 

Regards,
Valery.

From: Hu, Jun (Nokia - US)
Sent: 14 ноября 2016 г. 22:21
To: Tommy Pauly; IPsecME WG
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

Two comments:

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 15 Nov 2016 08:04:37 +0900

Hello Jun,

With regards to your first question, yes, the initiator would generally want to re-establish the TCP connection promptly. If it does not, the responder side may need to send a packet, and behave as if it gets no response (thus timing out and closing the IKE SA). We can add a line to specify that the re-establishment should be quick.

For the second question, I am not sure why the implementation would necessarily be maintaining an SA to TCP connection mapping. While it is possible to send traffic for different child SAs over different TCP flows, data for any of them should be accepted over any. That was the point of the line saying an implementation SHOULD allow receiving data on any connection. There is no need to send data for all child SAs to update the responder's mapping, if there is no mapping maintained. Traffic should not be blackholed if the responder uses an older connection that is still established, since the initiator should also not be enforcing a strict mapping. I agree that trying to maintain a mapping gets very complicated and adds packet overhead, which is why it is not recommended. Does this answer your question?

Thanks,
Tommy

> On Nov 14, 2016, at 10:21 PM, Hu, Jun (Nokia - US) <[email-masked]> wrote:
> 
> Two comments:
>

---

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Tue, 15 Nov 2016 01:48:47 +0000

However since the draft allows multiple TCP connections for the same tunnel; think of a case like following:
A tunnel has two CHILD_SA, each has its own TCP connection; SA-1 has TCP-1, SA-2 has TCP-2;
For some reason TCP-2 goes down on initiator side (TCP-1 is still up), so initiator create a TCP-3, for SA-2, if initiator only send IKE keepalive to update responder, so responder will change both SA-1 and SA-2 to TCP-3?

From: IPsec [mailto:[email-masked]] On Behalf Of Valery Smyslov
Sent: Monday, November 14, 2016 1:36 PM
To: Hu, Jun (Nokia - US); Tommy Pauly; IPsecME WG
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

Hi Jun,

Regards,
Valery.

From: Hu, Jun (Nokia - US)<mailto:[email-masked]>
Sent: 14 ноября 2016 г. 22:21
To: Tommy Pauly<mailto:[email-masked]>; IPsecME WG<mailto:[email-masked]>
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

Two comments:

> > On Oct 31, 2016, at 8:56 AM, [email-masked]<mailto:[email-masked]> wrote:
> >
> >
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Valery Smyslov <[email-masked]>
Date: Tue, 15 Nov 2016 11:18:53 +0900

What’s wrong with that?

As far as I understand the draft, the mapping between IKE/IPsec and TCP is loose,
so it seems that such a scenario is OK (Tommy corrects me if I’m wrong). 
Do you have any problems with it?

From: Hu, Jun (Nokia - US)
Sent: 15 ноября 2016 г. 10:48
To: Valery Smyslov; Tommy Pauly; IPsecME WG
Subject: RE: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

Hi Jun,

Regards,
Valery.

Two comments:

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 15 Nov 2016 11:26:28 +0900

I agree with Valery that there doesn't seem to be any problem here. The statement that the initiator is "creating a TCP-3 for SA-2" is not a scenario that we want to support, because there is not strict mapping between TCP connections and SAs. The responder can respond to both SAs on the same TCP connection, or it may not. Both sides should support any combination, and any implementation that refuses to accept packets will not be compliant with the spec.

Thanks,
Tommy

> On Nov 15, 2016, at 11:18 AM, Valery Smyslov <[email-masked]> wrote:
> 
> What’s wrong with that?
>  
> From: Hu, Jun (Nokia - US) <mailto:[email-masked]>
> To: Valery Smyslov <mailto:[email-masked]>; Tommy Pauly <mailto:[email-masked]>; IPsecME WG <mailto:[email-masked]>
> From: Hu, Jun (Nokia - US) <mailto:[email-masked]>
> To: Tommy Pauly <mailto:[email-masked]>; IPsecME WG <mailto:[email-masked]>
> > From: IPsec [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Tommy Pauly
> > > On Oct 31, 2016, at 8:56 AM, [email-masked] <mailto:[email-masked]> wrote:
> > >
> > >
> > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/>
> > >
> > > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03 <https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03>
> > >
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-03 <https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-03>
> > >
> > >
> > > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> > >
> > > [email-masked] <mailto:[email-masked]>
> > > https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>  
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Tue, 15 Nov 2016 02:33:18 +0000

I am totally fine with be able to receive on any TCP session; but to send a packet, system need know which TCP session to reach the peer for a given SA, so I think there is some kind mapping for egress;
So if you say "creating a TCP-3 for SA-2" is not a support case, then why initiator will create two TCP sessions for a given tunnel at first place?

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 14, 2016 6:26 PM
To: Valery Smyslov; Hu, Jun (Nokia - US)
Cc: IPsecME WG
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

Thanks,
Tommy

On Nov 15, 2016, at 11:18 AM, Valery Smyslov <[email-masked]<mailto:[email-masked]>> wrote:

What’s wrong with that?

From: Hu, Jun (Nokia - US)<mailto:[email-masked]>
Sent: 15 ноября 2016 г. 10:48
To: Valery Smyslov<mailto:[email-masked]>; Tommy Pauly<mailto:[email-masked]>; IPsecME WG<mailto:[email-masked]>
Subject: RE: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

Hi Jun,

Regards,
Valery.

Two comments:

> > submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
> >