[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [IPsec] Nudge on discussion of WG work item: IKE over TCP
From:       Paul Wouters <paul () cypherpunks ! ca>
Date:       2012-10-29 0:51:24
Message-ID: alpine.LFD.2.02.1210282048080.3978 () bofh ! nohats ! ca
[Download RAW message or body]

On Tue, 16 Oct 2012, Yoav Nir wrote:

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

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.

> > 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.
> 
> 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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


[prev in list] [next in list] [prev in thread] [next in thread]