headers
Mike Sullenberger | 1 Dec 2011 02:45
Picon
Favicon

Re: Discovery (Was: Preparing a charter change for P2P VPN)

It looks to me like this "discovery" ends up being:

  1. a new end-node securely connecting to a known trusted server (hub)
  2. registering itself (attributes, protected subnets) with the hub
  3a. waiting for another end-node to find it via the hub, because that
      end-node has data traffic for it.
  3b. or trying to find another end-node via the hub, because it has
      data traffic for it.

Step 1. Is logically done using some level of IPsec, though I would say that
	you also need another tunneling protocol like GRE to facilitate the
        other steps.

Step 2. The Attribute part of step 2. could be done via IKE or NHRP. I would
        argue for using NHRP, since it already has the base functionality
	and it would be easy to add more attribute passing.

Step 2. The advertising of protected subnets, could be done using IKE or NHRP,
        but if you use either of these then you would end up creating another
	Routing Protocol, which seems like a waste of time when there are 
	routing protocols that you could use for this (RIP, OSPF, BGP).

	As end-nodes come and go access to the protected networks that
	they serve comes and goes. So you need to be able to dynamically
	advertise and revoke access to these protected subnets.

	Also to provide redundancy you will likely have at least two
	end-nodes (securuty gateways) that are providing access to the
	same set of protected subnets.  To provide different levels of
	load-balancing and redundnacy you are going to need to be able
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Hoffman | 1 Dec 2011 02:56

Re: Discovery (Was: Preparing a charter change for P2P VPN)


On Nov 30, 2011, at 5:45 PM, Mike Sullenberger wrote:

> It looks to me like this "discovery" ends up being:
> 
>  1. a new end-node securely connecting to a known trusted server (hub)
>  2. registering itself (attributes, protected subnets) with the hub
>  3a. waiting for another end-node to find it via the hub, because that
>      end-node has data traffic for it.
>  3b. or trying to find another end-node via the hub, because it has
>      data traffic for it.

That is one way. Another way that has been described would be closer to:

1. An IPsec gateway that knows all of the networks it protects connects to a known trust server (introducer)
2. The gateway registers itself and its protected networks and their policies, or updates what is already
there for the gateway.
3. When another gateway asks the introducer how to reach a particular address, the introducer finds the
address in the collection and gives the information about that to the gateway.

Step 3 would probably be triggered by traffic. OTOH, if we expect the information from the introducer to
include a TTL / freshness period, the gateways might poll the introducer for everything it knows on a
period basis to reduce the route setup time.

--Paul Hoffman
Permalink | Reply | 0 comments |
headers
Yoav Nir | 8 Dec 2011 10:55
Picon
Favicon

Large Scale VPN

Hi all.

The discussion has died down a bit, so I thought I'd chime in with proposed charter text. What do people think
of the following?  The first paragraph is taken from Steve's email of 18-Nov.

Yoav

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.

The IPsecME working group will handle this large scale VPN problem by delivering the following:

* The working group will create a problem statement document including use cases, definitions and proper
requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last
call around October 2012.

* The working group will review and help publish Informational documents describing current vendor
proprietary solutions. These should be ready for IETF last call by August 2012.

* The working group will choose a common solution for the discovery and update problems that will satisfy
the requirements in the problem statement document. The working group may consider multiple proposals,
and then choose one to bring to the standards track.
Permalink | Reply | 17 comments |
headers
Paul Hoffman | 8 Dec 2011 17:04

Re: Large Scale VPN


On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote:

> 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.

I don't think "mesh" is a well-defined term here. How about "point-to-point"?

> The IPsecME working group will handle this large scale VPN problem by delivering the following:
> 
> * The working group will create a problem statement document including use cases, definitions and proper
requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last
call around October 2012.
> 
> * The working group will review and help publish Informational documents describing current vendor
proprietary solutions. These should be ready for IETF last call by August 2012.
> 
> * The working group will choose a common solution for the discovery and update problems that will satisfy
the requirements in the problem statement document. The working group may consider multiple proposals,
and then choose one to bring to the standards track.

We would need a deadline for the last item. I suggest "December 2013".

--Paul Hoffman
Permalink | Reply | 15 comments |
headers
Paul Clark | 7 Dec 2011 23:25

IPsec MIB confusion

In section 5 of the IPsec Security Policy Database MIB (RFC 4807), it makes reference to the spdIpHeaderFilterTable object in the overview and the tutorial, but that table is not listed in the MIB definition in section 6.  What am I missing?


-Paul

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 0 comments |
headers
Yaron Sheffer | 8 Dec 2011 19:14
Picon

Re: Large Scale VPN

We as a group can commit to deliverable #1 and #3 (problem statement and 
standardized solution). But deliverable #2 (vendor protocols) is mostly 
out of our hands. So before we approve this charter, I would like to 
hear from people that represent vendors that they can commit to publish 
such a draft for their favorite solution. With a mostly complete -00 
draft in, say, 4/2012. Please respond to the list or privately to Paul 
and myself.

Also, I suggest to replace the sentence "The working group may consider 
multiple proposals, and then choose one to bring to the standards 
track." by "The working group may standardize one of the vendor 
solutions, a combination of several, or a new protocol." The latter is 
clearer, at least to me.

Thanks,
     Yaron

On 12/08/2011 06:04 PM, Paul Hoffman wrote:
> On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote:
>
>> 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.
> I don't think "mesh" is a well-defined term here. How about "point-to-point"?
>
>> The IPsecME working group will handle this large scale VPN problem by delivering the following:
>>
>> * The working group will create a problem statement document including use cases, definitions and
proper requirements for discovery and updates. This document would be solution-agnostic. Should reach
WG last call around October 2012.
>>
>> * The working group will review and help publish Informational documents describing current vendor
proprietary solutions. These should be ready for IETF last call by August 2012.
>>
>> * The working group will choose a common solution for the discovery and update problems that will satisfy
the requirements in the problem statement document. The working group may consider multiple proposals,
and then choose one to bring to the standards track.
> We would need a deadline for the last item. I suggest "December 2013".
>
> --Paul Hoffman
>
> _______________________________________________
> IPsec mailing list
> IPsec <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 12 comments |
headers
Paul Hoffman | 8 Dec 2011 19:24

Re: Large Scale VPN

On Dec 8, 2011, at 10:14 AM, Yaron Sheffer wrote:

> We as a group can commit to deliverable #1 and #3 (problem statement and standardized solution). But
deliverable #2 (vendor protocols) is mostly out of our hands. So before we approve this charter, I would
like to hear from people that represent vendors that they can commit to publish such a draft for their
favorite solution. With a mostly complete -00 draft in, say, 4/2012. Please respond to the list or
privately to Paul and myself.
> 
> Also, I suggest to replace the sentence "The working group may consider multiple proposals, and then
choose one to bring to the standards track." by "The working group may standardize one of the vendor
solutions, a combination of several, or a new protocol." The latter is clearer, at least to me.

+1 to both.

--Paul Hoffman
Permalink | Reply | 0 comments |
headers
Yoav Nir | 8 Dec 2011 21:00
Picon
Favicon

Re: Large Scale VPN


On Dec 8, 2011, at 6:04 PM, Paul Hoffman wrote:

> 
> On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote:
> 
>> 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.
> 
> I don't think "mesh" is a well-defined term here. How about "point-to-point"?

point to point sounds to me too much like the old host-to-host IPsec idea that never quite took off. I know
this is part of Chris's use case, but I don't think that's our main focus. I can live with either
point-to-point or mesh, but either way we'll have to define it in the first deliverable.

> 
>> The IPsecME working group will handle this large scale VPN problem by delivering the following:
>> 
>> * The working group will create a problem statement document including use cases, definitions and
proper requirements for discovery and updates. This document would be solution-agnostic. Should reach
WG last call around October 2012.
>> 
>> * The working group will review and help publish Informational documents describing current vendor
proprietary solutions. These should be ready for IETF last call by August 2012.
>> 
>> * The working group will choose a common solution for the discovery and update problems that will satisfy
the requirements in the problem statement document. The working group may consider multiple proposals,
and then choose one to bring to the standards track.
> 
> We would need a deadline for the last item. I suggest "December 2013".

Works for me. I was hesitant to suggest a date.
Permalink | Reply | 1 comment |
headers
Yoav Nir | 8 Dec 2011 21:06
Picon
Favicon

Re: Large Scale VPN


On Dec 8, 2011, at 8:14 PM, Yaron Sheffer wrote:

> We as a group can commit to deliverable #1 and #3 (problem statement and 
> standardized solution). But deliverable #2 (vendor protocols) is mostly 
> out of our hands.

That's why I used "review" and "help" rather than "write" or "produce".

> So before we approve this charter, I would like to 
> hear from people that represent vendors that they can commit to publish 
> such a draft for their favorite solution. With a mostly complete -00 
> draft in, say, 4/2012. Please respond to the list or privately to Paul 
> and myself.
> 
> Also, I suggest to replace the sentence "The working group may consider 
> multiple proposals, and then choose one to bring to the standards 
> track." by "The working group may standardize one of the vendor 
> solutions, a combination of several, or a new protocol." The latter is 
> clearer, at least to me.

Agree. How about:

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 point-to-point 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.

The IPsecME working group will handle this large scale VPN problem by delivering the following:

* The working group will create a problem statement document including use cases, definitions and proper
requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last
call around October 2012.

* The working group will review and help publish Informational documents describing current vendor
proprietary solutions. These should be ready for IETF last call by August 2012.

* The working group will choose a common solution for the discovery and update problems that will satisfy
the requirements in the problem statement document. The working group may standardize one of the vendor
solutions, a combination, an superset of such a solution, or a new protocol.
Permalink | Reply | 10 comments |
headers
Paul Hoffman | 8 Dec 2011 21:15

Re: Large Scale VPN

On Dec 8, 2011, at 12:00 PM, Yoav Nir wrote:

> 
> On Dec 8, 2011, at 6:04 PM, Paul Hoffman wrote:
> 
>> 
>> On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote:
>> 
>>> 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.
>> 
>> I don't think "mesh" is a well-defined term here. How about "point-to-point"?
> 
> point to point sounds to me too much like the old host-to-host IPsec idea that never quite took off.

The points can be (and are likely to be) gateways.

> I know this is part of Chris's use case, but I don't think that's our main focus. I can live with either
point-to-point or mesh, but either way we'll have to define it in the first deliverable.

I believe that we need to have a sensible definition for the charter.

Is there a good definition of "mesh VPN" we can add to the proposed charter text? Is there a preference for
"point-to-point", maybe with a better definition?

--Paul Hoffman
Permalink | Reply | 0 comments |

Gmane