Yoav Nir writes:
> > I agree with the concerns Yaron has raised here. I would much prefer
> > that this be negotiated via notifications during the SA_INIT exchange.
> > I see a number of benefits:
> >
> > 1. The TCP listening port could be explicitly exchanged (as data in the
> > notification), rather than always assumed 500. This would allow
> > operation in parallel with any legacy/proprietary use of that server
> > port, and in general more deployment flexibility.
> >
> > 2. Since INIT always happens over UDP, as responder, I can immediately
> > close any TCP connection that doesn't present an IKE header with an SPI
> > I recognize.
>
> I don't agree that IKE_SA_INIT should always be over UDP. The first
> flight of packets from the server in TCP includes at most 2 packets.
> Then the server has to wait for an ACK to continue. Same goes for
> the request. So beginning with the IKE_AUTH exchange for TCP can add
> up to three roundtrips. This is a shame when dealing with a peer
> that we know supports IKE.
I do not understand your statement above. Especially what does "server
has to wait for an ACK to continue"? If there is space in window there
is no need to wait for ACKs, you can just send next packet to the
other end immediately when you have it.
In normal case I would expect the flow being something like
UDP: IKE_SA_INIT --->
<--- UDP: IKE_SA_INIT response
TCP Syn --->
<--- TCP Syn, ACK
TCP Ack --->
TCP IKE_AUTH ---> (note there is no need to wait anything here this
packet can go immediately after the TCP Ack, if
I remember right the data could even be in the
ACK pcaket, but operating systems APIs usually
do not support it)
<--- TCP ACK (this might be delayed and combined
with the packet below)
<--- TCP IKE_AUTH response
(IKEv2 Negotiation done)
TCP Ack --->
I probably need to read your draft before I comment further, as it
might already be explained there.
> > 3. It fits better with the IKEv2 design of never assuming the peer has
> > capabilities beyond the base requirements without a notification/vendor
> > payload indicating otherwise.
>
> Just as clients may start IKE over UDP port 4500, they should be
> able to begin IKE_SA_INIT over TCP. We can still have those
> notifications for clients using UDP for IKE_SA_INIT, but it would be
> silly to send them over TCP.
The reason UDP port 4500 is allowed for even IKE_SA_INIT is that the
client might have prior knowledge that the other end do support NAT-T.
It might have had connection few minutes ago, that got teared down for
some reason and it wants to re-establish it, or it might have been
configured always to use port 4500. Note, that NAT_DETECTION_*_IP
packets are supposed to be included even then...
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
