On Fri, 4 Mar 2016, Dr. Karan Verma wrote: [ Did this go way of-topic? This does not relate to DDOS at all? ]
1. The root CA certificate corresponding to the server certificate must be installed on the client computers in the Trusted Root Certification Authorities per-computer certificate store. The client computer must be able to validate the server certificate as being signed by a trusted root CA.
Unless other AUTH mechanisms are used?
2. If I keep my user and server key to a 2048-bit one it appears to be fine.
You are lucky. 2048 bit certificates regularly cause fragmentation.
There's an RFC for this and support on recent Strong swan releases but the client has to ask for it during initial negotiation and the BB10 client does not. The result is that longer (and more-secure) keys won't work -- if you have either a 4096-bit server certificate or a 4096-bit user cert the VPN will not come up.
Yes, strongswan, libreswan and even iOS I think support fragmentation for IKEv2.
3. First, we have incompatibility between IPsec AH and NAT. This is because AH header incorporates the IP source and destination addresses in the keyed message integrity check and therefore NAT will invalidate message integrity check by changing address fields. This makes A unusable in the presence of NAT devices. ESP doesn't have this problem because it doesn't incorporate the IP header inits keyed message integrity check, so changes in IP header will not conflict with ESP's integrity protection.
You should not use AH. Use ESP_NULL instead in Tunnel Mode.
A more serious problem that affects both AH and ESP is incompatibility between transport layer checksums and NAT. This problem occurs with AH and ESP in transport mode.
Don't use Transport Mode. The few bytes gained are not worth the hassle.
There is also incompatibility between IKEv2 address identifiers and NAT. Some phases of IKEv2 use IP addresses as identifiers. Modification of these addresses through NAT will cause mismatch between identifiers and the addresses in the IP header. The solution to this problem might be the use of user IDs or FQDNs that are independent of IP addresses.
I dont understand this at all. For any incoming IKE request that is not an IKE_INIT request, you have the SPI numbers that uniquely identify the IKE SA to match. In IKE_AUTH you are told the AUTH method to use, which can be anything. Outside of IKE_INIT and IKE_AUTH you are already authenticated and have your SPI's to match your connection.
IKE protocol requires use of fixed source and destination ports. This also causes incompatibility with NAT. One possible scenario that might cause problems is when multiple hosts behind the NAT (NAPT to be precise) initiate IKE SAs to the same responder. Mechanism is needed to allow the NAPT to DE multiplex the incoming IKE packets from responder.
The NAT box will assign a different outgoing port for the second client trying to use port 4500 as outgoing source port. There is no problem.
This is typically accomplished by translating the IKE UDP source port on outbound packets from initiator. Because of that responders must be able to accept IKE traffic from a various source ports (other than 500 on which is IKE running)
You are mixing up source port and destination port here. IKE daemons only need to listen on port 500 and 4500. And they should accept any port for the incoming IKE packets.
, and must reply to that port. The somewhat similar problem, but in it's own category, are the incompatibilities between overlapping SPD entries when using NAT.
We have a draft for that we will be updating soon. But you can also work locally on this. For example on linux you can add MARKing to the packet and have two identical SPD's that only differ by the mark. That means you can receive and reply conflicting SPDs fine, except you cannot initiate traffic to one specific SPD unless you manually mark your packet.
There are situations when responder could send packets down the wrong IPsec SA because of overlapping SPD entries.
That would be an implementation bug. This could happen when initiating
hosts behind NAT use their source IP addresses in Phase 2 identifiers.
I think you refer to two machines on 192.168.1.1 behind two different NAT routers? There should not be a problem but again you will need to use our natt draft lik approach or MARKing of some kind. Another problem between ESP and NAT lies
in thein compatibility between IPsec SPI selection and NAT. Since IPsec ESP traffic is encrypted, only way for NATs to know how to demultiplex incoming packets is to inspect information’s in the IP and ESP header. These
NAT's don't need to demultiplex anything. They just need to conntrack the local IP's and ports they assigned, and return reply traffic appropriately. This has no relation whatsoever to the packets. Of course this uses ESPinUDP.
information’s are usually destination IP address, IPsec SPI and security protocol (every SA is uniquely determined by this three elements). Because of independent selection of incoming and outgoing SPIs it is possible that the NAT will deliver the incoming IPsec packets to the wrong place when two hosts behind the NAT attempt to create IPsec SAs at the
No that is not possible unless you have a broken implementation. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
