Subject: [IPsec] Notes from P2P VPN Side Meeting

From: Stephen Hanna <[email-masked]>
Date: Fri, 18 Nov 2011 01:59:56 -0500

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.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 18 Nov 2011 13:33:55 +0200

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:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.