I read the draft yesterday. I wasn't surprised. That in itself was a surprise.
It's exactly what I thought the problem is from the beginning. There was no big mystery requirement that I didn't understand. The only thing I found weird was the belief that RFC4301 SPD configuration had to be "hard". There are certainly lots of hard to use products with really poor user interfaces, which perhaps suggest that the underlying mechanisms are really difficult to work with, but that doesn't mean this is a hard problem. The dual trunk scenario should perhaps be further motivated and clarified. Are there some situations where a spoke should not contact another spoke directly, but in fact should contact a hub closer to the other spoke. I can see some solutions where a hub would not have complete knowledge of the mesh, and so would in fact simply punt a connection closer. Another thing that I would like clarified is whether or not traffic should flow through the hub while the connection to the spoke is brought up. Finally, say my laptop is normally part of such a mesh (as a /32,/128 subnet). When I'm "trapped" behind a NAPT, I naturally use NAT-traversal to get out and join the MESH. Now, what happens if I come to the office, which is itself part of the MESH. This is not a new problem, btw, but normally I have only a single tunnel to bring up or down. Now that I have all these tunnels and policy. Should any of this MESH continue to be used? Are there some non-convex topologies where this can be important (should some traffic be double encrypted as a result?), or is it all just out of scope. (We dealt with these things as implementation challenges when combining an extruded IPsec tunnel with RFC4322. We had co-terminal tunnels of the near kind, which was solved, and co-terminal tunnels of the far kind, which we did not manage to implement) For the above, consider a laptop/tablet which might now have multiple exit routes via 3G+wifi+wired... and that it's moving. <implementator hat> I saw nothing at all that prevents it from being solved with RFC4322, using software that has been out there for over ten years. And I've implemented this in the past. There are some IKEv2 enhancements (involving traffic selectors) that would be nice to have, and perhaps for some situations could become critical due to resource constraints. </implementator hat>
pgpZuQis52iRa.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
