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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
