Yoav Nir writes: > I think section 2.1 makes it clear that the TCP connections should > be short-lived. Specifically, I would not send liveness checks, > which are very short requests and responses over TCP. I would use > UDP exclusively for those.
As liveness checks are supposed to check whether other end is there, not whether the path you send packets is there, it does not matter which path is used. And also note that you are NOT supposed to send periodic liveness checks like some implementations are doing. You are only supposed to do them when you suspect something is wrong (i.e. no traffic from other end, ICMP error message, or in this case the TCP connection we have with other end is reset). > > - The draft kind of skirts the question, and I would prefer to be clear: > > we are standardizing new behavior for IKEv2, not for IKEv1. > > I think it's suitable for both versions. If this gets adopted by the > working group, and people object to standardizing new stuff for > IKEv1, I can remove all mention of it. I would be strongly against adding this to IKEv1. IKEv2 was published 7 years ago, people should start updating their products... > <hat type="vendor"> > Our present implementation works with IKEv1, and has done so for > over 10 years. I could submit an Informational describing how Check > Point's implementation does IKEv1 over TCP. But just as new ciphers > would apply to both versions, I think this transport can also be > independent of version. > </hat> I would be more happy if you would as a vendor try to get people to move IKEv2 not add some stuff to IKEv1. IKEv2 is much more robust protocol and provides standarized features for lots of things IKEv1 does with private extensions (configuration mode, xauth etc). > > - There are obvious advantages to negotiating this capability: you don't > > have clients sending SYNs that will get rejected by firewalls/endpoints. > > Especially in IKEv2 where the heavy stuff only happens on message #3. > > SYN/SYN-ACK or SYN/RST is a kind of negotiation. Besides, sending a > notification over UDP that says "I support TCP" doesn't help much, > because it cannot vouch for the path allowing TCP port 500. I I have not read your draft so I do not know how you do it (I am on vacation now), but I think capability indication is needed, not really negotiation, but indication from either or both ends that they do support this so it is worth of trying to establish the TCP connection. At least that would provide some better feedback, i.e if the other end do support it but TCP connection fails, then there is most likely firewall filtering TCP packets, compared to the other end not supporting this feature at all. > wonder if there's an actual use case for increasing the length field > of payloads, so that IKE can support larger payloads when working > over TCP. One use for this would be to send large CRLs in a CERT > payload. We already have Hash and URL format for transmitting large CERTs, and we have mechanism in the PKIX to provide CRLs over some other transport than IKE. I think we can keep the current 64k limit. > > > - 2.3: disallowing retransmissions implies a change on both transmitter > > and receiver, and I think this is unnecessary. You can change the IKE > > timeouts on the sender to achieve the same behavior, even if rarely an > > odd retransmission does slip through. > > I guess. There is a MUST in section 2.4 for keeping retransmission > detection, so when implementing the transmitter, you can do either. > It doesn't make sense to retransmit at the application level when > TCP does it for you. With MOBIKE it does make sense to retransmit at the application level, as it might be possible that the path used to send the first packet failed, but some other path can be used. Also if you send request over TCP and get TCP reset back, it might be useful to try to recreate the TCP connection and then retransmit. Some cases NAT boxes simply forget about the TCP session (reboots) and you only get indication that this TCP session is reset after you try to send data over the connection. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
