Subject: [IPsec] IPsec SPD search

From: Sheng Hsin Lo <[email-masked]>
Date: Wed, 6 Jun 2012 22:54:39 +0800

Hello,

Should the SPD search in IPsec support longest prefix match(LPM)?

Thanks.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Jun 2012 18:06:25 +0300

> Should the SPD search in IPsec support longest prefix match(LPM)?

Hi

The answer is no. The SPD is an ordered list of entries, and the first match is the one to follow. 

RFC 4301 defines a decorrelation algorithm (section 4.4.1 and appendix B) that remove overlaps for quicker searches, but that does not change the result fo the SPD search, which is first-match.

Hope this helps

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Jun 2012 11:11:05 -0400 (EDT)

> RFC 4301 defines a decorrelation algorithm (section 4.4.1 and appendix B) that remove overlaps for quicker searches, but that does not change the result fo the SPD search, which is first-match.

The *swan implementations when using KLIPS use longest prefix match.
When using NETKEY/XFRM you get the first match behaviour. The latter
causes all kinds of problems.

Apart from the RFC stating so, what is the reasoning behind favouring
an "arbitrary top down list" over longest prefix match?

Paul

---

From: Markku Savela <[email-masked]>
Date: Wed, 06 Jun 2012 18:15:30 +0300

> an "arbitrary top down list" over longest prefix match?

For example, if your policy only specifies remote or local port,
like 80 (to cover all HTTP traffic, regarless of origin). It
would be hard to see how longest match would apply to it?

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Jun 2012 11:21:55 -0400 (EDT)

> would be hard to see how longest match would apply to it?

You first match on the longest prefix. If you have multiple candidates,
you match on the most specific traffic selector, favouring protocol over
ports.

That seems more predictable and stable then "whatever connection loaded
first"?

Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jun 2012 16:30:43 -0400

>>>>> "Paul" == Paul Wouters <[email-masked]> writes:
    Paul> That seems more predictable and stable then "whatever
    Paul> connection loaded 
    Paul> first"?

1) Please don't confuse the Linux NETKEY/XFRM's API with RFC4301.
   RFC4301 says that the admin controls the order of the policies, while
   XFRM does not give the admin any real control, and embeds policies
   in the kernel in a really really really bad way, rather than in a
   policy daemon. 

2) Please don't confuse KLIPS with RFC4301.  KLIPS implements the
   policy, and yes, it uses longest-prefix match for destination, then
   source, then port ranges, etc. in essentially the way that the
   decorelation algorithm describes.  The de-corelation algorithm with
   independantly invented by Luis Sanchez/BBN, myself and others, around
   the time of RFC2401 hitting the press.

3) Pluto actually provides an ordering mechanism between policies which
   is the ordering mechanism for policies as specified in 4301.

 -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.