Paul Wouters writes: > >> I think it is a server's policy issue. It can always restrict > >> the number of IPsec SAs from a single peer > >> by using NO_ADDITIONAL_SAS notification. > >> The document should not impose any restrictions here, IMHO. > > > > Agree. Implementations might also have different limits depending > > whether the other end is authenticated or unauthenticated, i.e. > > unauthenticated clients might only be able to create for example 10 > > Child SAs, and authenticated clients can create 1000 Child SAs... And > > btw child SAs are quite cheap, so the limit does not need to be 1 and > > 3... :) > > But what's the point? Just to protect th per-port IPsec SA's with > more PFS in CREATE_CHILD_SA ?
For some reason people wnat to turn on PFS on TLS, so that NSA cannot break all the http-connections by just stealing that one key from the server. For the same reason IKE users who already do Diffie-Hellman during the IEK SA creation, might want to do separate PFS for different Child SAs, just to make things harder for attacker. Again as we are talking about un-authenticated connections, NSA can just do MitM in the beginning, and gain all traffic, but that is active attack, which might get detected. Doing passive storing of the all traffic and then breaking Diffie-Hellman later provides better ways of staying undetected for them. If we do one 1024-bit Diffie-Hellman using un-authenticated exchange, then they can break that one 1024-bit Diffie-Hellman and get all traffic protected by each Child SA. If we do PFS for each Child SA then they need first to break the IKE SA Diffie-Helman and then for each traffic flow second one... There are people who want this kind of feature. Thats why this draft should not have any text restricting per-flow SAs... It might have comment saying that because clients are un-authenticated, there might be need for tighter resource limits than for authenticated clients. > It will only cause interop failures. The client will not pick a > host-to-host but picks say port 80 only. Then it wants port 443 and > gets NO_ADDITIONAL_SAS. Then it needs to drop the port 80 SA and > restart everything to get the full range single SA. Why should that cause interop failures? This is all standard RFC7296 stuff already. We are not changing anything here related to this. > If you are not authenticated, what is the point in splitting up the > traffic in different IPsec SA's per protocol or port? Causing more work for the passive monitoring people breaking your multiple 1024-bit Diffie-Hellmans, instead of just breaking one. And you might use shorter Diffe-Hellman groups for performance reasons than with authneticated use cases. > The only use case I have heard of that could apply, is the use case > of being mandated to NOT encrypt something for auditing purposes. But > traffic selectors really suck for "everything but sip and smtp and pop > and imap" :P Yes, usually traffic selectors are either per IP, or per-flow. Anything else are usually just silly... And for most normal authenticated use cases per-flow SAs are not really that useful, but we still have them in RFC7296, and I do not see any reason why they should be removed in this document. The most common use cases for per-flow SAs is when you have multiuser system where different users use different IKE SAs and per-flow SAs. I have not really seen those used that much lately... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
