In the section 1 there is text:
----------------------------------------------------------------------
Specifically, the messages of the IKE_AUTH
exchange can become quite large, as they may contain a chain of
certificates, an "Auth" payload (that may contain a public key
signature), CRLs, and some configuration information that is
carried in the CFG payload.
----------------------------------------------------------------------
In addition to the IKE_AUTH there is another big class of UPD packets
which can be large, and which might get fragmented, i.e udp
encapsulated nat traversal IPsec UDP packets. If the protocol run
inside the transport mode IPsec connection sends large packets they
may get fragmented too. This should not be problem for TCP, as PMTU
should make the packets small enough not to get them fragmented, but
if you run some UDP based application then this might be issue.
For tunnel mode IPsec traffic, the gateway can fragment inner packets
before wrapping them to ESP, so the outer ESP packets visible to nat
box are not fragmented.
Another thing that should be mentioned here that IKEv2 already have
several optional features which will solve the large IKE_AUTH packet
problem: the certificate can be replaced with hash and url format; The
child sa negotiation can be postponed with childless sa exchange
(removes the traffic selectors); Postponing the child sa creation also
allows running the cfg mode exchange can be done as separate
informational exchange (i.e. removing even configuration payloads from
the IKE_AUTH packet); Using elliptic curves instead of RSA will make
auth payload smaller. All these optional features should make the
IKE_AUTH packet to be less than 300 bytes.
I think this document should mention those optional features, as
implementing them allows much more efficient protocol than
transmitting the IKE_AUTH over TCP.
In section "3. Operational Considerations" there is text saying:
----------------------------------------------------------------------
An alternative method, that is probably easier for the Initiator to
implement, is to do an entire "mission" using the same transport. So
if TCP is needed for long messages and an IKE SA has not yet been
created, the Initiator will open a TCP connection, and perform all
2-4 requests needed to set up a child SA over the same connection.
----------------------------------------------------------------------
Note, that NAT detection might not work properly, when IKE_SA_INIT is
run over TCP (i.e. over different protocol), especially if IKE_SA_INIT
is first tried with UDP, and then retransmitted over different
protocol. The IKEv2 RFC5996 says that "A retransmission from the
initiator MUST be bitwise identical to the original request." (section
2.1 or RFC5996), which means we cannot modify the NAT_DETECTION_*_IP
payloads when switching from UPD to TCP. This might cause NAT to be
detected even when there is none there (i.e. the UDP source port is
500, but TCP source port is most likely going to be random).
Also I think this document should tell the justifications why the TCP
session is not kept alive all the time, but only created for sending
one packet and then immediately teared down. I assume the idea there
is that open TCP session actually requires quite a lot of resources
from the SGW, i.e. maintaining the send and receive windows requires
tens of kilobytes of memory. Of course the downside of such short TCP
sessions is that sending one exchange over TCP now requires 2 round
trips of delay, and most likely around 10 packets, compared to the 1
round trip and 2 packets.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
