Subject: [IPsec] Preparing a charter change for P2P VPN

From: Stephen Hanna <[email-masked]>
Date: Mon, 21 Nov 2011 15:09:07 -0500

The conclusion of Wednesday night's P2P VPN side meeting
was that we would start a new thread on the proposed
ipsecme charter change and resolve the open questions
by email. Let's start off with the text that came out
of Wednesday's meeting and the questions raised there.

The text from the meeting describing the problem to
be solved was:

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.

And the main open questions from the meeting were:

* Should we create a problem statement and requirements
  draft?

* Should we create a Standards Track document with
  the solution or just document existing proprietary
  vendor solutions in Informational RFCs?

Please respond to this email with comments on the
problem description text and on the questions.
I think we need to reach consensus on those basic
matters before we can work on final proposed text
for the charter change.

Thanks,

Steve

---

From: Nico Williams <[email-masked]>
Date: Mon, 21 Nov 2011 15:44:12 -0600

> * Should we create a problem statement and requirements

The problem statement seems simple enough that if there is to be just
one Standards-Track RFC with one (or more) solution(s), then the
problem statement could be folded into the one S-T RFC.

>  vendor solutions in Informational RFCs?

What are the existing proprietary solutions?  I'd prefer to see a
Standards-Track solution, but that's not incompatible with documenting
an existing proprietary solution, if there are any such that can
reasonably be made an Internet standard.

Nico
--

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 22 Nov 2011 10:27:31 +0200

Hi Nico,

even if we later fold the problem statement (PS) into the 
standards-track document, the motivation behind such a PS is to achieve 
common understanding of the problem *before* all of our attention is 
diverted towards the technical solution. What worked for us in the past 
is to have a separate PS/requirements document, and to kick off the 
solution document as soon as the PS leaves the working group. I.e., 
without waiting for the PS to actually get published.

Thanks,
     Yaron

On 11/21/2011 11:44 PM, Nico Williams wrote:
> On Mon, Nov 21, 2011 at 2:09 PM, Stephen Hanna<[email-masked]>  wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Geoffrey Huang <[email-masked]>
Date: Tue, 22 Nov 2011 09:40:52 -0800

At the meeting, someone made a suggestion about just documenting use cases.  If this is the same thing as a requirements document, then I'm in favor of it.

If a requirements draft is much more involved -- I would be against it.

Also, I do believe a standards track document would be useful, but documenting existing vendor solutions would not preclude us from also pursuing a standard.

-geoff 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Hanna
Sent: Monday, November 21, 2011 12:09 PM
To: [email-masked] WG
Subject: [IPsec] Preparing a charter change for P2P VPN

The conclusion of Wednesday night's P2P VPN side meeting was that we would start a new thread on the proposed ipsecme charter change and resolve the open questions by email. Let's start off with the text that came out of Wednesday's meeting and the questions raised there.

The text from the meeting describing the problem to be solved was:

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.

Please respond to this email with comments on the problem description text and on the questions.
I think we need to reach consensus on those basic matters before we can work on final proposed text for the charter change.

Thanks,

Steve

---

From: "Ulliott, Chris" <[email-masked]>
Date: Tue, 22 Nov 2011 22:06:33 +0000

Classification:UNCLASSIFIED

I think the problem as stated represents the issue quite well although I'd be tempted to add discovery to the list of issues.

What I've taken awa from the various debates is that there are differing views as to whether the problem can be sorted by combining existing RFC's in a standard way or whether we need a new RFC for some (yet to be agreed) gaps. Personally, from trying to do this with a practical deployment, discovery seems to be the only gap - so perhaps a good way forward would be to take the use cases in the draft and then expand on them. From this, we can work out if there are any gaps? It's not as formal as a requirements document, but could work to help everyone better understand the problem.

Chris

[This message has been sent by a mobile device]

----- Original Message -----
From: Stephen Hanna [mailto:[email-masked]]
Sent: Monday, November 21, 2011 08:09 PM
To: [email-masked] WG <[email-masked]>
Subject: [IPsec] Preparing a charter change for P2P VPN

Thanks,

Steve

****************************************************************************
Communications with GCHQ may be monitored and/or recorded 
for system efficiency and other lawful purposes. Any views or 
opinions expressed in this e-mail do not necessarily reflect GCHQ 
policy.  This email, and any attachments, is intended for the 
attention of the addressee(s) only. Its unauthorised use, 
disclosure, storage or copying is not permitted.  If you are not the
intended recipient, please notify [email-masked].  

This information is exempt from disclosure under the Freedom of 
Information Act 2000 and may be subject to exemption under
other UK information legislation. Refer disclosure requests to 
GCHQ on 01242 221491 ext 30306 (non-secure) or email
[email-masked]

****************************************************************************

The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 27 Nov 2011 17:50:12 +0200

> * Should we create a problem statement and requirements

Yes, but I wouldn't mind if that PS/Requirements/Use-case document never got published. It's a means, not an end.

>  vendor solutions in Informational RFCs?

Both.

Yoav

---

From: Michael Ko <[email-masked]>
Date: Mon, 28 Nov 2011 16:11:02 -0800

I agree that discovery is one of the issues that should be explored.  Due to 
the dynamic nature, automated discovery is an important requirement for the 
user to set up a secure connection with an authorized network node.  For a 
direct end-to-end connection between two parties when both are located 
behind different NATs, TURN resorts to the use of publicly addressable 
rendezvous servers.  Can the existing proprietary vendor solutions discussed 
in the side meeting handle this situation?

Mike

----- Original Message ----- 
From: Ulliott, Chris
To: [email-masked]' ; [email-masked]'
Sent: Tuesday, November 22, 2011 2:06 PM
Subject: Re: [IPsec] Preparing a charter change for P2P VPN UNCLASSIFIED

I think the problem as stated represents the issue quite well although I'd 
be tempted to add discovery to the list of issues.

What I've taken awa from the various debates is that there are differing 
views as to whether the problem can be sorted by combining existing RFC's in 
a standard way or whether we need a new RFC for some (yet to be agreed) 
gaps. Personally, from trying to do this with a practical deployment, 
discovery seems to be the only gap - so perhaps a good way forward would be 
to take the use cases in the draft and then expand on them. From this, we 
can work out if there are any gaps? It's not as formal as a requirements 
document, but could work to help everyone better understand the problem.

Chris

----- Original Message -----
From: Stephen Hanna [mailto:[email-masked]]
Sent: Monday, November 21, 2011 08:09 PM
To: [email-masked] WG <[email-masked]>
Subject: [IPsec] Preparing a charter change for P2P VPN

Thanks,

Steve

The original of this email was scanned for viruses by the Government Secure 
Intranet virus scanning service supplied by Cable&Wireless Worldwide in 
partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On 
leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or 
recorded for legal purposes.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Nov 2011 16:38:32 -0800

On Nov 28, 2011, at 4:11 PM, Michael Ko wrote:

> I agree that discovery is one of the issues that should be explored.  Due to the dynamic nature, automated discovery is an important requirement for the user to set up a secure connection with an authorized network node.  For a direct end-to-end connection between two parties when both are located behind different NATs, TURN resorts to the use of publicly addressable rendezvous servers.  Can the existing proprietary vendor solutions discussed in the side meeting handle this situation?

When people here advocate for "discovery", what do they mean? Do you mean:

- hubs can receive information from the spokes about what addresses the spoke gateways protect

- hubs can proactively go out and find spokes and then ask what addresses each spoke gateway protects

- something else

--Paul Hoffman

---

From: Melinda Shore <[email-masked]>
Date: Mon, 28 Nov 2011 15:49:16 -0900

> - hubs can proactively go out and find spokes and then ask what addresses each spoke gateway protects

It seems to me that the TURN example was maybe a little inapt, at
least in the context of "discovery," and that may tend to muddy
something that might look vaguely like a problem statement.  TURN
helps two guys that are NATted help set up a connection - it's a
rendezvous mechanism.  A rendezvous mechanism might be needed here,
as well, but that's at least somewhat independent of the question of
trying to find the guy with whom you want to rendezvous in the
first place.

I also wonder if there might not be a crapload of overlap with
routing, based on how you've asked the questions quoted above.

Melinda

---

From: Michael Ko <[email-masked]>
Date: Mon, 28 Nov 2011 17:31:57 -0800

To establish a secure connection between two authorized network nodes,  some 
of the critical management tasks that are required include the following:

1. Discover if the network nodes that a user is authorized to access are 
currently online and active.  (One can always resort to timeouts to 
determine if the peer is online or not, but being able to ascertain the 
status of the peer quickly would be nice.)

2. Discover the functional attributes associated with these authorized 
network nodes.

3. Discover the location of the authorized network nodes.  (E.g., current IP 
address)

4. Determine if accessing the network node requires going through a relay 
(e.g., TURN).  Discover the location of the relay if it is needed.

5. Determine the parameters needed to establish a secure connection between 
the two network nodes.

6. Discover, via inquiry or advertisement, other authorized network nodes as 
they become active and available.

If we use the hub as the entity to provide this "discovery" function, then 
the statement "hubs can receive information from the spokes about what 
addresses the spoke gateways protect" comes closest to meeting the 
requirment, although the information to be "discovered" include the above 
list and goes beyond just addresses.

Mike

----- Original Message ----- 
From: Paul Hoffman
To: IPsecme WG
Sent: Monday, November 28, 2011 4:38 PM
Subject: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)

On Nov 28, 2011, at 4:11 PM, Michael Ko wrote:

> I agree that discovery is one of the issues that should be explored.  Due 
> to the dynamic nature, automated discovery is an important requirement for 
> the user to set up a secure connection with an authorized network node. 
> For a direct end-to-end connection between two parties when both are 
> located behind different NATs, TURN resorts to the use of publicly 
> addressable rendezvous servers.  Can the existing proprietary vendor 
> solutions discussed in the side meeting handle this situation?

- hubs can receive information from the spokes about what addresses the 
spoke gateways protect

- hubs can proactively go out and find spokes and then ask what addresses 
each spoke gateway protects

- something else

--Paul Hoffman

---

From: Melinda Shore <[email-masked]>
Date: Mon, 28 Nov 2011 16:44:47 -0900

On 11/28/2011 04:31 PM, Michael Ko wrote:
> To establish a secure connection between two authorized network nodes,
> some of the critical management tasks that are required include the
> following:
> 3. Discover the location of the authorized network nodes. (E.g., current
> IP address)
> 4. Determine if accessing the network node requires going through a
> relay (e.g., TURN). Discover the location of the relay if it is needed.
> 5. Determine the parameters needed to establish a secure connection
> between the two network nodes.
> 6. Discover, via inquiry or advertisement, other authorized network
> nodes as they become active and available.
> If we use the hub as the entity to provide this "discovery" function,
> then the statement "hubs can receive information from the spokes about
> what addresses the spoke gateways protect" comes closest to meeting the
> requirment, although the information to be "discovered" include the
> above list and goes beyond just addresses.

Could you go into more detail about what you mean by "user" here,
and what "authorized" means?  Are you going out and querying an
authorization system?  Are you expecting that a pile of attributes
is going to be returned as the result of an authentication?  Is
a "user" some sort of authenticated credential, or something along
the lines of an NAI, or an IP address, or ... ?

Melinda

---

From: Michael Ko <[email-masked]>
Date: Mon, 28 Nov 2011 18:21:24 -0800

Melinda,

My comments are inline.

Mike
----- Original Message ----- 
From: Melinda Shore
To: [email-masked]
Sent: Monday, November 28, 2011 5:44 PM
Subject: Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)

> above list and goes beyond just addresses.

Could you go into more detail about what you mean by "user" here, and what 
"authorized" means?

[mk] A "user" is a network node that wants to connect with a peer node, 
preferably in a direct end-to-end connection.  (If you can suggest a better 
term than "user" that will cause less confusion, I will use it instead.)  A 
"user" may not be "authorized" to connect with all peer nodes in the domain.

Are you going out and querying an authorization system?

[mk] The peer node determines which nodes are authorized to connect with it. 
So the user is not querying an authorization system per se, but since there 
can be many many peer nodes, it would be nice if a "user" can find out which 
peer nodes it is authorized to access.  So it is more like a central 
repository for information rather than an authorization system.

Are you expecting that a pile of attributes is going to be returned as the 
result of an authentication?

[mk] With the central repository, the administrator determines what 
attributes are to be stored.  A "user" can query for only the attributes 
that it is interested in.  So for example, a "user" first authenticates with 
the central repository.  It can then uploads its own attributes or downloads 
attributes of peer nodes that it is authorized to access.  In this case one 
of the attributes that a peer node will upload would be the list of nodes 
that are authorized to access it.

Is a "user" some sort of authenticated credential, or something along the 
lines of an NAI, or an IP address, or ... ?

[mk] A "user" will have an IP address, but whether it has an NAI depends on 
the domain where it belongs.  And for determining access authorization, a 
"user" will need to have a "user name" or some unique identification in the 
domain since the peer node will not know the IP address of a mobile "user".

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Mon, 28 Nov 2011 18:29:16 -0900

On 11/28/11 5:21 PM, Michael Ko wrote:
> preferably in a direct end-to-end connection. (If you can suggest a
> better term than "user" that will cause less confusion, I will use it
> instead.) A "user" may not be "authorized" to connect with all peer
> nodes in the domain.

I still find this very unclear.  If a user "has" an IP address, how
is the user identified, and how does the network know who it is?  That
is to say, there's apparently some sort of identity process/
authentication going on here prior to an IKE exchange, and I
cannot tell from your requirements (and frankly I find them too
vague to be called requirements, really) what that identity is,
who's participating, how it's transacted, or what sort of token/
credential/whatever represents that identity, let alone how it's
actually going to be used as the basis for authorizations.  Then,
there's the whole question of how you're going to authorize this
stuff.

I don't think you've got anything in here that's specific enough
to be charterable.

Melinda

---

From: Yoav Nir <[email-masked]>
Date: Tue, 29 Nov 2011 10:23:27 +0200

> - hubs can proactively go out and find spokes and then ask what addresses each spoke gateway protects

I would define discovery something like this:

Node A (either a client or a gateway) has a packet bound for host 194.29.35.43. It asks "the universe" how to encrypt traffic to that host:
 - What is the address of the gateway protecting 194.29.35.43 (could be the host itself, or could be none)
 - What ID and credential (certificate or PSK) will the peer show
 - What ID and credential should I show
 - What other addresses does this gateway protect

In this discovery process, "the universe" could be a pre-configured hub (pretty much what the Cisco and Juniper solutions do), a special-use server (as in the architecture in Michael's presentation) or maybe the DNS. But all this data needs to be returned.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Nov 2011 07:55:21 -0800

On Nov 28, 2011, at 5:31 PM, Michael Ko wrote:

> To establish a secure connection between two authorized network nodes,  some of the critical management tasks that are required include the following:
>  
> 1. Discover if the network nodes that a user is authorized to access are currently online and active.  (One can always resort to timeouts to determine if the peer is online or not, but being able to ascertain the status of the peer quickly would be nice.)
>  
> 2. Discover the functional attributes associated with these authorized network nodes.
>  
> 3. Discover the location of the authorized network nodes.  (E.g., current IP address)
>  
> 4. Determine if accessing the network node requires going through a relay (e.g., TURN).  Discover the location of the relay if it is needed.
>  
> 5. Determine the parameters needed to establish a secure connection between the two network nodes.
>  
> 6. Discover, via inquiry or advertisement, other authorized network nodes as they become active and available.
>  
If we use the hub as the entity to provide this "discovery" function, then the statement "hubs can receive information from the spokes about what addresses the spoke gateways protect" comes closest to meeting the requirment, although the information to be "discovered" include the above list and goes beyond just addresses.

> In this discovery process, "the universe" could be a pre-configured hub (pretty much what the Cisco and Juniper solutions do), a special-use server (as in the architecture in Michael's presentation…

So, there are two divergent views of what "discovery" is. Some people are saying it is discovery by the centralized points (introducers) of the addresses protected by remote gateways and the policies needed to reach them; some people are saying it is discovery by the remote gateways of the addresses protected by other gateways and the policies needed to reach them. These are quite different.

Our task would be simpler if we only used the second definition (Yoav's) for "discovery". I propose that we call how introducers discover which addresses gateways protect "map-making" (even though it also involves collecting additional information such as policies). I further propose that there is a requirement for gateways to be able to send introducers map-making information for themselves, but the process by which an introducer uses that information (such as when two gateways claim the same protected addresses) is out of scope.

--Paul Hoffman

---

From: Michael Ko <[email-masked]>
Date: Tue, 29 Nov 2011 12:37:44 -0800

Consider the case of a mobile user.  It is not sufficient for the user to 
identify himself using his current IP address.  Therefore some other 
identification means is necessary, perhaps in the form of NAI.  Whatever 
this identification mechanism is will be used in the authentication process 
with the central repository.  But in stating the problem, I want to avoid 
narrowing it down to be the NAI, or some other form, as that should be 
defined when we come to proposing a solution for the problem.

Mike
----- Original Message ----- 
From: Melinda Shore
To: Michael Ko
Cc: [email-masked]
Sent: Monday, November 28, 2011 7:29 PM
Subject: Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)

Melinda

---

From: Michael Ko <[email-masked]>
Date: Tue, 29 Nov 2011 13:36:44 -0800

I can live with the term "map-making" in referring to the functions provided 
by the centralized repository ("introducer") that I discussed in my earlier 
e-mail.  Note that there is quite a bit of overlap between "map-making" and 
"discovery".  In both cases, a node wants to find out "What ID and 
credential (certificate or PSK) will the peer show" and "What ID and 
credential should I show".  For "discovery", there is also the need to find 
out "What other addresses does this gateway protect" (presumably all 
addresses protected by the gateway) whereas for "map-making", a node only 
wants to find out which nodes it is authorized to access.  Also for 
"discovery", a node already knows that it "has a packet bound for host 
194.29.35.43" before it contacts "the universe", whereas for "map-making", a 
node does not necessarily know the IP address of the peer it wants to reach 
when it contacts the central repository.

Mike
----- Original Message ----- 
From: Paul Hoffman
To: IPsecme WG
Sent: Tuesday, November 29, 2011 7:55 AM
Subject: Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)

On Nov 29, 2011, at 12:23 AM, Yoav Nir wrote:

> Node A (either a client or a gateway) has a packet bound for host 
> 194.29.35.43. It asks "the universe" how to encrypt traffic to that host:
> In this discovery process, "the universe" could be a pre-configured hub 
> (pretty much what the Cisco and Juniper solutions do), a special-use 
> server (as in the architecture in Michael's presentation) or maybe the 
> DNS. But all this data needs to be returned.

So, there are two divergent views of what "discovery" is. Some people are 
saying it is discovery by the centralized points (introducers) of the 
addresses protected by remote gateways and the policies needed to reach 
them; some people are saying it is discovery by the remote gateways of the 
addresses protected by other gateways and the policies needed to reach them. 
These are quite different.

Our task would be simpler if we only used the second definition (Yoav's) for 
"discovery". I propose that we call how introducers discover which addresses 
gateways protect "map-making" (even though it also involves collecting 
additional information such as policies). I further propose that there is a 
requirement for gateways to be able to send introducers map-making 
information for themselves, but the process by which an introducer uses that 
information (such as when two gateways claim the same protected addresses) 
is out of scope.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Tue, 29 Nov 2011 16:17:41 -0600

> when it contacts the central repository.

For credentials it's easier to think in terms of administrative
domains, and the mapping operation is admin_domain->cert_store.  (I
say certificate store because the node may have multiple certificates
for different users' traffic, though this is not really common at all,
and will almost never happen on a mobile node, which is what needs
discovery.)

For target IP addresses... mapping addresses to administrative domains
will be the challenging task, particularly when private-use addressing
is involved (for example, one can't use the public DNS/DNSSEC for
discovery in that case).  For private-use addresses my instinct says
that each administrative domain should operate a lookup service and
that the node should have a domain precedence list, asking each domain
in turn until one claims the target address or all fail to claim it
(the lookups can be parallelized though).  For public-use addresses
the DNS (using DNSSEC) should be able to provide the answer.

As for nearest SG for a given administrative domain, well, I'm
thinking of anycasting and multicasting, as well as SRV RRs.

That's several operations then:

 - anycast/multicast to find topologically close SGs

 - DNS (SRV RR lookups) to find a domain's SGs

 - a protocol by which to ask a domain which SGs to use for
   specific addresses (probably as an IKEv2 extension as the
   SGs will know best)
   (this can double as the protocol for private-use address to
   admin. domain mapping)
   (this protocol should probably export IGP route metrics, with
   the SG having access to the IGP routing table, obviously)

 - DNS (w/ DNSSEC) to map public-use addresses to admin.
   domains

 - a local admin. domain -> cert [store] lookup operation

Or have I misunderstood the problem space?

Nico
--

---

From: Michael Ko <[email-masked]>
Date: Tue, 29 Nov 2011 16:21:31 -0800

That seems like a good starting point.

Mike
----- Original Message ----- 
From: Nico Williams
To: Michael Ko
Cc: Paul Hoffman ; IPsecme WG
Sent: Tuesday, November 29, 2011 2:17 PM
Subject: Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Nov 2011 17:31:29 -0800

At this point, we are trying to state requirements. You have already ran full-force into proposed solutions.

Having said that, I think your proposed solution is overkill for "discovery".

> thinking of anycasting and multicasting, as well as SRV RRs.

That's "discovery by looking around". I propose that a much simpler solution is "discovery by listening for trusted parties to register with you their information". That is, the introducer has a list of trusted gateways (which might be other introducers), and it listens for them to tell it what addresses they are responsible for and the policies that are associated with them. There should also be a way for a gateway to ask an introducer what the introducer knows about the gateway.

> Or have I misunderstood the problem space?

You have one view, I have a different one, and the rest of the WG should be chiming in about which they think are required for the problem of P2P VPN.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Tue, 29 Nov 2011 19:39:43 -0600

> At this point, we are trying to state requirements. You have already ran full-force into proposed solutions.

Looking at the sorts of solutions that might be in scope can help me
understand the problem space by illustration, particularly when new
[to me] terminology is used that confuses me.  I'm proposing nothing
in particular so much as illustrative concepts.

> That's "discovery by looking around". I propose that a much simpler solution is "discovery by listening for trusted parties to register with you their information". That is, the introducer has a li…

I see.  That makes sense, but you have to see the space of SGs or
other "introducers" that you know about.  They might multicast for you
to discover them.

> You have one view, I have a different one, and the rest of the WG should be chiming in about which they think are required for the problem of P2P VPN.

I don't yet have a view.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Nov 2011 17:48:33 -0800

> in particular so much as illustrative concepts.

Noted.

> other "introducers" that you know about.  They might multicast for you

That's a push model; I would propose a pull model based on existing trust relationships. What do others think?

--Paul Hoffman

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Tue, 29 Nov 2011 19:04:37 -0800

We agree with Paul. It does look like overkill to us. 

We could have NHRP-like messaging. When a spoke establishes preconfigured
spoke-to-hub (s2h), spoke will also does registration with HUB (policy,
protected networks, PAD). Registration information would involve networks
this particular spoke protects, SPD and PAD information.

"Discovery" can be initiated by spoke or it could by hub.

Spoke initiated:
When spoke1 wants to spoke2, spoke1 sends resolution request to HUB. Hub,
will resolves public IP address and SPD/PAD information of spoke2 to spoke1.
Thus spoke1 can trigger direct tunnel to spoke2.

Hub initiated:
When spoke1 wants to talk to spoke2, it sends message to HUB via static
tunnel (as generally done in HUB and Spoke scenario). Since HUB is aware
of spoke2 information, HUB may ask spoke1 to establish direct tunnel to
Spoke2.

Today NHRP resolves IP addresses. Having NHRP-like, we may resolve non-ip-address 
(like IKE ID Payload type). This will solve Mike Ko scenario, where user1 wants to 
talk to user2 (where users are not bound by IP address). 

Here user1 and user2 are similar to spoke1 and spoke2. Where user1 and user2 establish 
tunnel to HUB/universe/map-making, just like spokes do.

-- Praveen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Hoffman [[email-masked]]
Sent: Tuesday, November 29, 2011 5:48 PM
To: Nico Williams
Cc: IPsecme WG
Subject: Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)

Noted.

--Paul Hoffman