Subject: [IPsec] Nudge on discussion of WG work item: IKE over TCP

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Oct 2012 12:02:48 -0700

Greetings again. draft-ietf-ipsecme-ike-tcp-00.txt has been out for over a month and has received no discussion. Please review this short draft and comment on the mailing list.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Oct 2012 23:14:21 -0400 (EDT)

> Greetings again. draft-ietf-ipsecme-ike-tcp-00.txt has been out for over a month and has received no discussion. Please review this short draft and comment on the mailing list.

Thanks for the reminder.

I've read the draft and discussed it in Vancouver as well. I'm in favour
of adopting it. Some notes,

I know no one wants to define this for IKEv1, but I'd still prefer to
keep this in sync between IKEv1 and IKEv2.

I don't neccessarilly agree with the 1.1 non-goals. While I understand
this is not done primarily to avoid administrative filters, I see no
reason why to go out of our way to make it easy to filter IKE/IPsec.
If IKE could signal a TCP port along with the IKE_TCP_SUPPORTED payload
this would allow people so more freedom with running on different ports,
or even kickstarting IKE over another protocol (instant message,
whatever). I think the two octets are well spent for this.

Should the initiator also send IKE_TCP_SUPPORTED to the responder? The
initiator/responder roles could switch around at rekey, and it would
be useful to the initial responder (now initiator) whether or not it
can or should just start with TCP. Although it could deduce this from
having received a connection on TCP in the previous exchange. I'm not
sure on this one.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Tue, 16 Oct 2012 13:11:48 +0200

On Oct 16, 2012, at 5:14 AM, Paul Wouters wrote:

> of adopting it.

Well, you got it. It's already a working group draft.

> keep this in sync between IKEv1 and IKEv2.

I agree, and there's nothing stopping you (or me) from implementing this for IKEv1, but the group has spoken. See similar discussions about Brainpool curves.

> whatever). I think the two octets are well spent for this.

True. But do you think it's a common case, where the responder is behind a filter that drops TCP port 500, but that responder knows of a different port that is open? I suppose the responder could be behind some NAT device with the ability to map a forwarded port on the NAT device. I guess this makes sense. But then you have the initiator opening a connection to a random port. That has a far greater chance of getting filtered on the initiator side (firewalls tend to drop what they don't recognize).

At least in our firewall, FTP got special treatment - the control connection is monitored to recognize and allow the ports that are used by the data connections, but I don't think we can expect the firewall makers repeat this effort for IKE with random ports.

> having received a connection on TCP in the previous exchange. I'm not

I guess, but rekey doesn't require TCP, as it doesn't have the IKE_AUTH exchange. It may be useful so that next time the original responder can begin the Initial exchange with TCP.

> 
> Paul
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 16 Oct 2012 15:27:54 +0300

Yoav Nir writes:
> True. But do you think it's a common case, where the responder is
> behind a filter that drops TCP port 500, but that responder knows of
> a different port that is open? I suppose the responder could be
> behind some NAT device with the ability to map a forwarded port on
> the NAT device. I guess this makes sense. But then you have the
> initiator opening a connection to a random port. That has a far
> greater chance of getting filtered on the initiator side (firewalls
> tend to drop what they don't recognize). 

If initiator is behind NAT and uses some of those protocols to talk to
the NAT / FW and request a TCP port that will get forwarded to it then
this sending that port number inside the IKE notify payload would be
useful, in case the responder ever needs to reconnect back to him.

Also quite often firewalls have been set up so that all incoming
connections not explicitly allowed are forbidden, but all outgoing
connections not expiicitly forbidden are allowed. Now when the
initiator sets up the TCP listener port by talking to the NAT / FW,
then responder can connect to that port if needed, and responders NAT /
FW most likely will allow responder to connect to that port without
any special configuration. 

> At least in our firewall, FTP got special treatment - the control
> connection is monitored to recognize and allow the ports that are
> used by the data connections, but I don't think we can expect the
> firewall makers repeat this effort for IKE with random ports.

This is because firewalls try to do this without the help of the FTP
client / server. There are now protocols which allows client / servers
to connect to the NAT / FW and ask for this kind of services, thus
there is no need for NAT / FW to look inside the data packets and find
out the ports. 

> I guess, but rekey doesn't require TCP, as it doesn't have the
> IKE_AUTH exchange. It may be useful so that next time the original
> responder can begin the Initial exchange with TCP. 

You are assuming that only reason to use TCP is because the IKE_AUTH
packet is so big it gets fragmented. There has been also some comments
that using TCP also helps going through NAT / FW boxes, in which case
TCP is required to do any exchanges.

I have not read the latest version, it is on my todo list, I will get
back with more specific comments when I have time to read it.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 16 Oct 2012 17:15:11 +0400

Hi,

a few remarks regarding interaction with NAT traversal.

1. In case there's a NAT in between and IKE_AUTH is done over TCP,
    there's no event of switching to UDP ports 4500 (which usually takes 
place in IKE_AUTH).
    a) Which ports should use responder if it wants itself to initiate new 
Exchange over UDP
        or just wants to send a UDP encapsulated ESP packet to initiator? I 
see one possibility -
        responder must wait untill Initiator initiates any subsequent 
Exchange over UDP 4500
        or sends some UDP encapsulated traffic - only after that responder 
could learn
        the ports NAT is allocated for this mapping. But in general this may 
never happen -
        IKE SA could be established with no triggering packet from initiator 
("Connect" button).
    b) In case initiator is behind NAT it seems that responder can't use 
ephemeral TCP
        for any exchange it initiates, can it? And it can't initiate over 
UDP untill
        get learned the ports NAT has allocated (see clause above).

2. Draft says that retransissions could be done over different transport.
    In case IKE_SA_INIT request is first sent over UDP and then 
retransmitted
    over TCP, what about NAT_DETECTION_SOURCE_IP content? According to
    RFC5996 the retransmitted message MUST be identical to original,
    but in this case source port of TCP session will most likely be 
different
    from port original message was sent from, that will lead
    to erroneous NAT detection.

3. Related to above: RFC5996 allows to make IKE_SA_INIT request directly to 
UDP 4500
    instead of 500. The draft says that TCP transport is using port 500.
    Because only one NAT_DETECTION_DESTINATION_IP can be included
    In IKE_SA_INIT, we again face the problem of erroneous NAT detection.

4. If ports are included in COOKIE calculation, retransmissions of
    IKE_SA_INIT containing COOKIE over different transport will be rejected.

Regards,
Valery Smyslov.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 28 Oct 2012 20:51:24 -0400 (EDT)

> At least in our firewall, FTP got special treatment - the control connection is monitored to recognize and allow the ports that are used by the data connections, but I don't think we can expect the…

I'm not saying that I want firewall makers to do that. I am saying they
protocol should allow me to implement it. I might want to have a machine
that listens for IKE on all udp and tcp ports. I'm simply asking for an
optional method to convey ports. An option most people can leave at just
"500" if they only want to do IKE on tcp port 500.

> I guess, but rekey doesn't require TCP, as it doesn't have the IKE_AUTH exchange. It may be useful so that next time the original responder can begin the Initial exchange with TCP.

So can we make this an "initiator MAY also send IKE_TCP_SUPPORTED" ?

Paul