Subject: [IPsec] Please comment on Steve's P2P draft

From: Yaron Sheffer <[email-masked]>
Date: Mon, 12 Mar 2012 23:06:22 +0200

Hi,

Steve's document 
http://tools.ietf.org/html/draft-ietf-ipsecme-p2p-vpn-problem-00 happens 
to be (almost) the only thing on our agenda for Paris. I am sure once 
you've read it you will have some comments to discuss on this list: do 
the use cases make sense? Are there additional ones? Are they presented 
in sufficient depth to derive requirements? And so on.

We would prefer to get this discussion going *before* Paris, so that we 
can use the F2F meeting to focus on the most thorny issues.

Thanks,

     Yaron

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Mar 2012 21:19:25 -0400

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>