I definitely think that the authors of this draft (I'm mostly just the editor) need a good answer about why RFC 4322 doesn't cover the use cases. Mostly, the starting point is different.
RFC 4322 begins with nodes that have no prior trust relationship, and builds opportunistic bridges between them. The problem here is that groups of nodes that have trust relationships between them, but not between every pair of them. They want communications that now go through some hub gateway to go directly from spoke to spoke. On 10/14/11 3:48 PM, "Michael Richardson" <[email protected]> wrote: > >>>>>> "Yoav" == Yoav Nir <[email protected]> writes: > Yoav> A little. Also like GET-VPN and AC-VPN and Provider-1 > Yoav> (apologies to all the vendors I've missed) > > Yoav> Those are some of the incompatible solutions by individual > Yoav> vendors. > >And RFC4322. > >FreeSWAN has a number of local controls whereby one simply lists the >CIDRs that one wishes to be "secure or fail" vs ones that are "nice to >be secure". Many people have implemented MESHs by distributing the >reverse DNS. > >What it is missing in IKEv1 is a way to turn the host<->host tunnels >into subnet<->subnet tunnels, and that would be easy to do in IKEv2 with >the TS. > > > >> Sounds like TED: > >> > >> >http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.html > >> > >> Dan. > >> > >> On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote: > >>> Hi all > >>> > >>> For years, one of the barriers to the adoption of IPsec was that > >>> configuration didn't scale. With thousands of peers, the PAD and > >>> SPD would become unwieldy, so even where IPsec was deployed it > >>> was often built in hub-and-spoke configurations, not because > >>> policy demanded this, but because it was more convenient to > >>> configure. Individual vendors have incompatible solutions for > >>> this, but they only work with that vendor's products, and within > >>> the same administrative domain. > >>> > >>> In this draft, we are proposing that the IPsecME working group > >>> take on a working item to first define the problem, and then > >>> offer solutions that will make IPsec scale better and in an > >>> inter-operable way. > >>> > >>> We plan to hold a side meeting in Taipei, and we welcome > >>> comments both before and at that meeting. > >>> > >>> Yoav > >>> > >>> http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt > >>> http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 > >>> > >>> _______________________________________________ IPsec mailing > >>> list [email protected] https://www.ietf.org/mailman/listinfo/ipsec > >>> > >> > >> > >> > >> Scanned by Check Point Total Security Gateway. > > Yoav> _______________________________________________ IPsec mailing > Yoav> list [email protected] > Yoav> https://www.ietf.org/mailman/listinfo/ipsec >_______________________________________________ >IPsec mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/ipsec > >Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
