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: ipsec-boun...@ietf.org [ipsec-boun...@ietf.org] On Behalf Of Paul Hoffman [paul.hoff...@vpnc.org] 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 <paul.hoff...@vpnc.org> 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
