On 20 May 2011 c. 18:54:02 Reyk Floeter wrote:
> hi,
>
> On Thu, May 19, 2011 at 11:06:44PM +0400, Vadim Zhukov wrote:
> > This patch allows ipsecctl-like flow grouping along with current
> > behavior. It allows to write many-to-many policies in a more
> > compact way, see an example:
> >
> > ikev2 esp \
> > from { 1.2.3.4, 5.6.7.8 } to { 3.4.5.6, 4.5.6.7} \
> > from 7.8.9.0 to { 0.1.2.3, 2.3.4.5 } \
> > ...
> >
> > will create six flows:
> >
> > 1.2.3.4 -> 3.4.5.6
> > 1.2.3.4 -> 4.5.6.7
> > 5.6.7.8 -> 3.4.5.6
> > 5.6.7.8 -> 4.5.6.7
> > 7.8.9.0 -> 0.1.2.3
> > 7.8.9.0 -> 2.3.4.5
> >
> > Please note that you're still limited by MAX_IMSGSIZE, which is
> > about 7 flows, depending on arch. This will be addressed in
> > another patch.
>
> The difference between ipsec.conf and iked.conf and IKEv1 and IKEv2 is
> that an IKEv2 SA can have multiple flows, a.k.a. traffic selectors, in
> a single exchange while IKEv1 can only have one.
>
> So in ipsec.conf the code would expand it into multiple independent
> ike policies that would lead to multiple independent IKEv1 exchanges
> and SAs.
>
> With IKEv2 this would expand into a single IKEv2 SA with many traffic
> selectors that would have to fit into a single IKEv2 UDP packet
> (IKE_AUTH) which can lead to IP fragmentation and all kinds of
> problems. The current code does not prevent multiple traffic
> selectors as it is totally legal in IKEv2, but I would be careful with
> using macros to generate _many_ traffic selectors, or flows, in a
> policy. Maybe this is just a documentation issue or you need some
> additional length checking here to avoid/warn about excessive
> fragmentation (considering the 64k IPv4 limit as well).
Thank you (again :) ) for reviewing the diffs.
Then we need to warn user on parsing/configuring if length of resulting
IKE_AUTH packet will grow more than, say, 1400 bytes, yes?
I thought about generating new policy(-ies) for each "{ host, ... }"
construction, but this will effectively disallow multiple selectors
specification in such rules. This will not cause any harm to existing
setups, but looks ugly, and definitely is not intuitive for IKEv2 user.
>From the other side, if iked will support IKEv1 fully in future,
creating multiple policies will be a consistent behavior. What do you
think? I just want such rules compacting functionality, and trust you a
lot more in choosing underlying mechanism. :)
--
Best wishes,
Vadim Zhukov
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
