Thanks, Steve I agree that these notes reflect what happened in the meeting.
There was one item we did not discuss, and I think would be even less controversial. My presentation started with the statement that defining static meshes is complex and hard, and therefore people define stars. That is correct, but there is another reason for creating stars, which Andreas mentioned a few months ago. The spokes in a star topology are often located behind NAT, and therefore not reachable. A lot of systems managed to get around this using NAT traversal protocols such as TURN and STUN. In fact, many VoIP solutions such as Skype work well when both parties are behind NAT. I propose that we add an item to the IPsecME charter to describe a solution for IKE implementations (clients and gateways) when they're behind NAT. If this is agreed to by everyone, let's add this to the text we give Sean. If not, that's fine. We can go with the text we have now, and I will bring this up later. Yoav On Nov 18, 2011, at 2:59 PM, Stephen Hanna wrote: > Here are the notes that I took during Wednesday > night's side meeting on P2P VPN. Please send any > corrections to the list. > > Thanks, > > Steve > > ---------- > > Notes from November 16, 2011 P2P VPN Side Meeting > at IETF 82 > > Steve Hanna took notes. He did not duplicate the > slide content but focused on the discussion. The > slides can be found on the ipsec email list. > > After a bit of monkeying around with audio and > video issues, Yoav Nir gave a brief presentation > on the Problem Statement draft. This was followed > by equally brief presentations on the Cisco, > Juniper, and Checkpoint solutions for P2P VPN > from Frederic Detienne, Geoff Huang, and Yoav. > Last, Mike Irani gave a presentation on U.S. > Government efforts in this area and Mike Ko > gave a presentation on his ideas for Dynamic > Secure Interconnect (DSI). > > Steve displayed some draft language describing > the problem we're trying to solve: > > In an environment with many IPsec gateways and remote > clients that share an established trust infrastructure > (single domain or multi-domain), customers want to get > full mesh IPsec connectivity for efficiency. However, > this cannot be feasibly accomplished only with today's > IPsec and IKE due to problems with address lookup, > reachability, policy configuration, etc. We aim to > solve this problem in an interoperable manner using > IPsec and IKE and perhaps other new or existing IETF > standards. > > We agreed on a few edits. The parenthetical text about > domains was ambiguous about what kind of domains: trust > domains or administrative domains. We meant administrative > domains so we changed that text to say "in a single > administrative domain or across multiple domains". > We need to specify the ability to create and remove > mesh links as needed so we changed "full mesh IPsec > connectivity" to "on-demand IPsec capability". And > the last sentence is controversial since we haven't > agreed on how this problem should be solved so we > deleted this sentence for now. The resulting text is: > > In an environment with many IPsec gateways and remote > clients that share an established trust infrastructure > (in a single administrative domain or across multiple > domains), customers want to get on-demand mesh IPsec > capability for efficiency. However, this cannot be > feasibly accomplished only with today's IPsec and IKE > due to problems with address lookup, reachability, > policy configuration, etc. > > This text is not perfect but there did seem to be > a rough consensus in the room that this describes > the problem we want to solve. > > Paul Hoffman explained that we have several options > for next steps. We could ask ipsecme to create a > problem statement and requirements document then > move on to solutions. Or we could go straight to > a standards track solutions document. Or we could > just have vendors publish their existing proprietary > solutions as Informational RFCs. > > There was a good deal of discussion about the pros > and cons of these various approaches. Yaron Sheffer > and others said that we need a requirements document > since we clearly don't agree on the requirements. > Brian Weis said that this group doesn't do > requirements documents. Paul pointed out that > many vendors only care about interoperability > and value add. Chris Ulliott said his employer > (the U.K. Government) needs to pick a single > vendor-independent standard. > > We agreed to take a proposed ipsecme charter change > to the list and eventually to Sean Turner (our AD). > We'll start a new thread on this topic and resolve > the open questions on the charter change by email. > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
