Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth (fwd)

[Paul Wouters <[e-mail]>]

On Tue, 20 Jan 2015, Tero Kivinen wrote:

>>> Traffic Selectors
> ...
>>> And opens up the reverse attack of the server stealing the
>>> client's 8.8.8.8 traffic. Some more discussion and insights on this
>>> would be useful.
>
> Actually I think I am missing something. How can server steal clients
> 8.8.8.8 traffic? Even if it assigns client 8.8.8.7 IP address, that
> does not mean 8.8.8.8 is sent to the server. Server can assign 8.8.8.8
> for the client, which means that 8.8.8.8 traffic from the client does
> not go anywhere (i.e. it is routed to localhost, because client think
> it is his own IP), but that does not allow stealing traffic.

You are right. I was thinking of 8.8.8.8 <-> 0.0.0.0/0 but you don't do
that. I guess you would just use the equivalent of:

 	ip route add serverip src 8.8.8.8

> Also client can easily limit that address assigned to it via
> configuration payload must be from the private address range, as there
> is no reason for server to assign client real routable IP-address in
> unauthenticated user case. But again this is policy decision which
> implementations need to do.

Sure. and this discussion is suitable for the opportunistic document,
not auth_null. We should only put in a short summary here.

>> I think it is a server's policy issue. It can always restrict
>> the number of IPsec SAs from a single peer
>> by using NO_ADDITIONAL_SAS notification.
>> The document should not impose any restrictions here, IMHO.
>
> Agree. Implementations might also have different limits depending
> whether the other end is authenticated or unauthenticated, i.e.
> unauthenticated clients might only be able to create for example 10
> Child SAs, and authenticated clients can create 1000 Child SAs... And
> btw child SAs are quite cheap, so the limit does not need to be 1 and
> 3... :)

But what's the point? Just to protect th per-port IPsec SA's with
more PFS in CREATE_CHILD_SA ?

It will only cause interop failures. The client will not pick a
host-to-host but picks say port 80 only. Then it wants port 443 and
gets NO_ADDITIONAL_SAS. Then it needs to drop the port 80 SA and
restart everything to get the full range single SA.

If you are not authenticated, what is the point in splitting up the
traffic in different IPsec SA's per protocol or port?

The only use case I have heard of that could apply, is the use case
of being mandated to NOT encrypt something for auditing purposes. But
traffic selectors really suck for "everything but sip and smtp and pop
and imap" :P

We need less buttons and possibly interop issues, not more. So Instead
of trying to allow as much of IKEv2 features as you can dream of, lets
stick to those bells and whistles that make sense in the unauthenticated
scenario.

Paul