The main problem I have is that RFC 4322 makes two assumptions that don't always hold true in practical deployments.
Firstly, it assumes that a gateway or endpoint is able to configure entries in the secured DNS. For example, if I have an endpoint that is connected to a hotel wifi, I probably can't modify the reverse DNS to deploy my public keys or publish my gateway address. This also applies when you have mobile sites that may be using multiple bearers of opportunity such as SatCom / 3G etc. The second assumption is that I can secure the DNSSec deployment to the same level of trust, as I have in the network behind my IPSec device... again, this may not always be true. Chris -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Richardson Sent: Monday, October 17, 2011 2:53 PM To: [email protected] Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement >>>>> "Yoav" == Yoav Nir <[email protected]> writes: Yoav> I definitely think that the authors of this draft (I'm mostly Yoav> just the editor) need a good answer about why RFC 4322 doesn't Yoav> cover the use cases. Mostly, the starting point is different. Yoav> RFC 4322 begins with nodes that have no prior trust Yoav> relationship, and builds opportunistic bridges between them. No precisely true. 4322 says that we trust the central IP address delegation authority (IANA), and builds trust from there. Yoav> The problem here is that groups of nodes that have trust Yoav> relationships between them, but not between every pair of Yoav> them. They want communications that now go through some hub Yoav> gateway to go directly from spoke to spoke. So you can do this on a host<->host basis by implementing 4322, and then pulling (being a secondary using stock tools and protocols) the reverse zone from the hub (over your trusted link to the hub, or via TSIG/SIG(0), or just be IP address trust). What is (in the form of running code) missing is a way to transform the host<->host tunnels into subnet<->subnet tunnels. In IKEv2 we have a way to express the request now, what is missing is a way to express the authority statement. If subnets are on octet boundaries (or smaller, apply RFC2317), then it is pretty straightforward to search for TXT/IPSECKEY for the subnet. For CIDR subnets, which we can express in IKEv2, one could just confirm them all, but my bet is that there are no such networks that matter. ps: by the time IPSECKEY (RFC4025) was assigned, rfc4322 was pretty much in the can, and we did not have deployed code to be able to test the IPSECKEY RR easily. We decided that we would use the existence of IPSECKEY as a clue that we should try IKEv2 first. Openswan did not get an IKEv2 implementation until early 2008 though. What this means is that an RFC4322bis could properly specify semantics for IPSECKEY RR, and if they were a bit different than the semantics in 4322 for the TXT RR, that would be okay. === 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. **************************************************************************** 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 protected]. 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 protected] **************************************************************************** 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 protected] https://www.ietf.org/mailman/listinfo/ipsec
