On Mon, 13 Jan 2014, Valery Smyslov wrote:
I think that using NULL Auth method clearly identifies
anonymous users and allows to distingush them from regular ones.
Adding special "anonymous" ID here seems to be superfluous.
Than you should stick to that and not send any IDs whatsoever.
If we mandate ID to always be empty in case of NULL Auth,
then what to do if you still receive non-empty ID with NULL Auth?
Reject connection attempt or just ignore received ID?
For me the latter looks more appropriate (just follow
Postel's principle - be tolerant to what others do).
Yes, I would ignore it.
BTW, we have 3 possibility for inidicating "anonymous" ID.
1. Don't send ID Payload at all.
2. Send empty ID Payload (say, Type = 0, Len=0).
3. Send special ID Payload (say, Type=KeyId, Value="anonymous")
For me, case 3 looks the worst, I'd rather to avoid special values.
Case 1 looks the best from theoretical point of view, but
it will add complexity to already over-complicated IKE_AUTH
state machine (note, that currently ID Payload is mandatory).
For me case 2 looks like acceptible compromise.
I don't think this complicates the state machine that much, as it's
clearly distinct by the auth type none payload. My preference is for #1.
What do others think?
Why? Transport mode ESP has no issues with NAT, has it?
Yes it does, when multiple clients behind the same NAT router try to
connect to the same remote IPsec gateway.
Can you, please, elaborate? Where the problem come from?
Multiple clients behind the same NAT router with transport mode would use
different NATed UDP ports. The IPsec server can differentiate incoming
packets this way. But for outgoing UDP packet streams (not udp replies)
it would need to know which of the clients using the same IP this packet
would need to get encrypted to. You would need some kind of "mark"
asociating the SA with the socket. For *swan we did this with an "SAref"
marker. It would use ip_conntrack and put an SPI based iptables MARK
on the packt. For new connections originating from the IPsec gateway,
you could set a socket option (IP_IPSEC_BINDREF) if you know the SPI/MARK.
Why should it be mandatory? Why can't it be left to local security policy?
Because null auth is already weak?
So what? How auth (or the lack of it) is related to PFS?
Then again, I think PFS should be
made mandatory for all IPsec connections.
I tend to agree with you in general, but I still think it is a policy issue.
Stepping back, I agree that we could leave these things out of the auth
none specification.
So, I think that it is worth to separate NULL Auth from OE stuff
and describe all OE related issues in a separate draft, that
will use NULL Auth as a mechanism to skip authentication.
Sure, but than I do really want the ID parts not sent for NULL AUTH.
If draft says that in case of NULL Auth ID Payload SHOULD be sent empty
and MUST be ignored by receiver, will it satisfy you?
Yes, that would be perfect.
By the way, I do prefer the name "auth none" over "auth null". To me,
'null' embodies more of an error condition.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
