>>>>> "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.
pgpGg8MoOGEUS.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
