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 protected] [[email protected]] On Behalf Of Paul
>Hoffman
>[[email protected]]
>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 protected] 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 protected]
>https://www.ietf.org/mailman/listinfo/ipsec
>_______________________________________________
>IPsec mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/ipsec
+------------------------------------------------+
| Mike Sullenberger; DSE |
| [email protected] .:|:.:|:. |
| Customer Advocacy CISCO |
+------------------------------------------------+
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
