On Sun, Feb 12, 2012 at 3:54 PM, Paul Wouters <[email protected]> wrote: > 1) The responder can propose a narrowed proposal of the initiator's request > > a) What should the initiator do with packets that suddenly fall outside > the new narrowed proposal? drop them? send them in plain text? > (in other words, I'm trying to define a "local policy")
Local policy is not changed. If local policy requires that packets for some flow be sent with protection and there is no such SA, then the packets don't go. The local node should make a new proposal, possibly narrowed for the particular outgoing packet that's triggering SA negotiation. > b) If the initiator agrees to the narrowed proposal, how on earth should it > inform the user? Should the user know? (I think so, see a) Why should the user know? What matters is that policy be enforced. If there's no way to obtain a suitable SA, then you let the user know. > 2) If the initiator triggers the IKE on a packet, then it should send > that packet's source/destination as the first TSi/TSr, and the complete > tunnel proposal as the second TSi/TSr. The responder gets to pick which > traffic selector to use. > > a) If the packet is 10.a.b.c to 10.d.e.f, and the policy on the initiator > is 10.a.b.0/24 to 10/8, then why would it ever want to give the > responder an option to narrow it down to what will eventually become > a cascade of /32 <-> /32 Child SA's ? Because sometimes it's desirable to have per-flow SA pairs. >[...] > In other words, I find it really hard to come up with valid scenario's > of narrowing down policy as per RFC 5669 Section 2.9. And as a result, > I'm not sure how (and if) I should implement this part of the RFC. > > Am I wrong in that allowing narrowing on the initiator or responder is > not something that should be allowed per-default, but only after being > explicitely told to allow it? Or am I missing a (secure!) use case when > not allowing narrowing of traffic selectors per default? Narrowing proposals means having more SA pairs, basically. Does that have a negative impact on security? More, narrower SA pairs -> easier traffic analysis, perhaps. But beyond traffic analysis I see nothing wrong with lots of narrow SA pairs from a security point of view. From a performance p.o.v. there may be an issue (more SA pairs -> more keys and key schedules -> more cache pressure -> lower performance). Replay protection may affect the choice to narrow traffic selectors, IIUC. Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
