I think the key point here is that XFRM allows the policy administrator (be it human or software) to manage their own order by specifying the priority value in the policy when it is added. As I recall, the XFRM SPD just adds the policy at the correct point in the list to maintain a monotonic sequence of priorities.
Tim MacKenzie > >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Michael Richardson >Sent: Wednesday, June 06, 2012 1:31 PM >To: [email protected] >Subject: Re: [IPsec] IPsec SPD search > > >>>>>> "Paul" == Paul Wouters <[email protected]> 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 protected] http://www.sandelman.ottawa.on.ca/ |device >driver[ > Kyoto Plus: watch the video ><http://www.youtube.com/watch?v=kzx1ycLXQSE> > then sign the petition. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
