Sent from my iPhone
> On Jun 4, 2014, at 17:55, Yoav Nir <[email protected]> wrote: > > > > Section 2.2 says that “As peer identity is meaningless in this case, > Identification Data SHOULD be omited from ID Payload”([1]), and even if sent, > it MUST be ignored by IKE. So it’s really not provided. There wasn't consensus on that but I'm clearly if that opinion as well. > > That’s a good question. What prevents a random attacker from sending a TSr > covering IP address 8.8.8.8, and getting a whole bunch of DNS queries. That’s > easier than bugging the ISP or break the wifi password. Our implementation has a global option that allows only rfc1918 and related (eg 25/8) for NATT. We might be able to not need it with the Linux VTI hooks and NAT, but that's still a work in progress. For the protocol work I'd say that is all local implementation. >> I think that the opportunistic encryption use case given can not make any >> sense without reference to the PAD. > > I think that’s the hard part of any opportunistic IPsec. It’s not always > better than nothing, because you might be making it easier for Eve. > > Yoav > > [1] sic - “omitted” should have two t's > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
