Subject: Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)

From: Mike Sullenberger <[email-masked]>
Date: Wed, 30 Nov 2011 17:45:50 -0800 (PST)

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
	to prefer on path (SG) over another.

	All of these functions are capabilities that are already provided
	by routing protocols, so it would be a waste of time to have to
	provide inferior functionality in IKE.

	Note, if the end-node is a host that is only providing secure
	access to itself then perhaps it wouldn't need to advertise
	itself, the hub could add that advertisement into the network
	(routing protocol) on its behalf. 

Step 3a and 3b.  This functionality is already provided by NHRP.

Note, if you have two end-nodes in different security domains, then each
end-node is going to connect to its own trusted server (hub). Then any
attempt by the end-nodes to connect to each other will go through their 
respective hubs, and across a trusted interconnect between the hubs. At
that point any authorization and passing of security attributes that
the end-nodes need to use can be handled by their respective hub and then
the two end-nodes (if allowed) can build a direct secure connection and
send traffic to each other.

So by dividing this into securing traffic (IPsec), tunneling (GRE), finding
gloabl IP address of secure gateways/end-nodes (NHRP) and routing through
the VPN (routing protocol) you have solved the problem. 

Mike.

>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)
>
>On Nov 29, 2011, at 5:39 PM, Nico Williams wrote:
>
>> On Tue, Nov 29, 2011 at 7:31 PM, Paul Hoffman <[email-masked] wrote:
>> 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.
>
>Noted.
>
>>> On Nov 29, 2011, at 2:17 PM, Nico Williams wrote:
>>>> As for nearest SG for a given administrative domain, well, I'm
>>>> 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.
>>
>> 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.
>
>That's a push model; I would propose a pull model based on existing
>trust relationships. What do others think?
>
>--Paul Hoffman
>
>_______________________________________________
>IPsec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipsec
>_______________________________________________
>IPsec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipsec

+------------------------------------------------+
| Mike Sullenberger; DSE                         |
| [email-masked]                .:|:.:|:.         |
| Customer Advocacy              CISCO           |
+------------------------------------------------+

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Nov 2011 17:56:18 -0800

>  3b. or trying to find another end-node via the hub, because it has

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