Re: AF_KEY extended xfrm_state selector handling

["Michal Růžička" <michal.ruzicka@comstar.cz>]

>
> BTW, why not use xfrm instead? Then you dont have to worry about racoon.

What do you mean by this?
- Do you suggest that there is another IKE implemetation for Linux 2.6 IPSec 
stack which uses netlink socket (XFRM) for kernel communication? If so, 
would you please point me to it?
Or
- Do you mean to make racoon use the netlink socket (XFRM) instead of PF_KEY 
for the kernel communication? (Well I'm not brave enough to tackle that.)
Or
- Do you mean something completely else?

> Unless you care about running this in some other OS (I suspect these
> OSes probably have made use of SADB_EXT_ADDRESS_PROXY so that may be a
> futile effort in any case).

I can see this might be problem, but a conditional compilation of the 
relevant bits of racoon should be enough to cope with that.

>
>
> cheers,
> jamal
>
> PS:- Nothing stands out for me in your patch, so i have no comment; i


OK, could you please apply it then?

> wasnt sure if the concept of tcp/udp port meant much to the concept of a
> security association

It is crucial for the multiple clients behind the same NAT scenario.

>
>

Regards Michal