Herbert Xu wrote:
quoted text
> On Thu, Jan 22, 2009 at 10:31:32AM +0200, Timo Teräs wrote:
>> The (quickish) look on *swans would imply that for each
>> dynamic connection I would need to hand create a new connection
>> entity. Could be scriptable, but then I would somehow
>> need to make up connection names based on the IPs and always
>> inject full config by the admin tool.
> 
> They have templates for inbound connections on servers and also
> outbound connections which were used for Opportunistic Encryption.
> So you can adapt these to generate connections on demand.
> 
> Also creating/destroying connections at run-time is really easy
> without generating a full config at all by using ipsec whack.

I think I looked into openswan int he beginning in detail
and it had various problems. I think there wasn't netlink
stuff there either when I looked into it.

Looking at strongswan now, it does look a lot more usable.

But I don't like how IKEv2 is complitely separate from
IKEv1. Different daemons, different whack interface, etc.

There was some other things too why I decided to go for
ipsec-tools in the beginning. But it doesn't really matter
as long as I get IPsec.

So for the time being, I can have my patched kernel, fix
some of the swans and switch to it, or even write my own
IPsec keying manager if it comes to that. IPsec KM is not
that relevant for me, as long as it works.

quoted text
>> But if there's multiple nodes behind same public IP the xfrm
>> has two (or more) choices for which xfrm state to use. The
>> NAT-OA can be used as distinguishing factor. So when ip_gre
>> sends out packet, the xfrm can choose the correct xfrm state.
> 
> That's precisely what you don't want to do unless you trust all
> your peers equally.  The reason is that NAT-OA is not authenticated,
> i.e., I can choose any address to send over as NAT-OA and there
> is nothing you can do to stop me.
> 
> It was only ever intended to be used for fixing up the checksum
> so you can't safely use it for making policy/routing decisions.

In DMVPN/GRE case, the NAT-OA from IPsec would not be used
unless the NAT-OA is set on neighbour cache. This would not
happen unless NHRP can authenticate it. In DMVPN case you need
a valid certificate to give the ranom NAT-OA in any case. So
if you lie about your NAT-OA I can just revoke you.

Or do you have, other recommendations how to distinguish peers
behind same public IP than NAT-OA? Maybe we add the certificate
subject to xfrm state and neighbour cache. And use that?
That would certainly be authenticated. Would that be a better
approach? Or in general, allow a random token to be associated
with an xfrm state, so that we can connect neighbor cache in
gre interface to that specific state.

- Timo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html