Hello Dave there are some suggestions and comments:
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. If you are already using SSTP connections, then you can use the same certificate for both SSTP and IKEv2, as long as the certificate meets the CN and EKU requirements identified previously. Because root CA certificates are required on client computers when using SSTP, adding a certificate for IKEv2 that was created by the same CA as an SSTP certificate means that no client changes are needed. 2. If I keep my user and server key to a 2048-bit one it appears to be fine. But, if I try to use a 4096-bit certificate for either the machine or the user's authentication the negotiation fails over anything but a local network connection, and it appears the reason it fails is fragmentation. In short the keying never gets to the server and thus does not complete. 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. 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. 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. Namely, TCP and UDP checksums depend on source and destination addresses and ports because of their inclusion in "pseudo-header" during transport protocol checksum calculations and verifications. When a NAT box changes source and/or destination address/port it can-not change the checksum since it's protected by either or both ESP and AH. The partial solution is to use ESP in tunnel mode, but in this case inner IP address, protected by NAT, is visible to the node. 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. 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. 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), 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. There are situations when responder could send packets down the wrong IPsec SA because of overlapping SPD entries. This could happen when initiating hosts behind NAT use their source IP addresses in Phase 2 identifiers. 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 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 same destination simultaneously. Namely, this destination could choose same SPIs and there is no way for NAT to know to which SA belong incoming packets from this destination. Thus, NAT neither knows where to deliver these incoming packets. Technique that can alleviate this problem is that receiving host (the one who generated same SPIs in our case) allocate a unique SPI to each unicast SA. We have already mentioned that protocols who embed IP address within payload have a problem with NAT boxes. IPsec and its protocols aren't exception – payload could be integrity protected and NAT couldn't translate IP addresses embedded within payload. Solution for this problem is to install ALGs (Application Layer Gateways)on the host or security gateway. These ALGs should have a possibility of operating on application traffic before IP sec encapsulation and after IPsec decapsulation the NAT provides IPv6 nodes with specific IPv6 prefix. This prefix is retrieved from the NAT external IPv4 address. A part from providing the prefix, NAT also encapsulates IPv6 packets in IPv4 for transport to other 6to4 nodes or relays. This method gives a possibility for communication without problems between an IPv6 node using IPsec and other nodes inside the IPv6 or 6 to 4 area. Unfortunately, 6to4 is not universally usable. It is an appropriate solution where a single NAT separates a client and the VPN gateway but it cannot be used where multiple NATs are deployed between client and VPN gateway. Reason for this is that forming of mentioned IPv6 prefix requires the assignment of a routable IPv4 address to the NAT. Peers that support IPv6 need a little upgrade to be 6to4compatible, while NATs require many extensions to support 6 to 4. On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) < [email protected]> wrote: > All: > > With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I believe > the draft is shaping up nicely, but needs additional review. To that end, > this message starts a Working Group Last Call (WGLC) for > draft-ietf-ipsecme-ddos-protection-04. > > The version to be reviewed is > https://tools.ietf.org/id/draft-ietf-ipsecme-ddos-protection-04.txt. > > Please send your comments, questions, and edit proposals to the WG mail > list until March 18, 2015. If you believe that the document is ready to be > submitted to the IESG for consideration as a Standards Track RFC please > send a short message stating this. > > Best Regards, > Dave > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > -- Best Regards Dr. Karan Verma Assistant Professor Computer Science and Engineering Dept. Central University Rajasthan, India Website: www.drkaranverma.com Phone: +917568169258
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
