Hi Tero,
thanks for your detailed review. Please see inline.
I commented only the issues where we disagree with Paul.
On the other hand same section says that ID_NULL SHOULD only be used
with NULL authentication method. In which scenarios do you think
ID_NULL can be used when using normal authentication? I.e. which is
the exception for the SHOULD?
It could be used, for example, in the first IKE_AUTH message sent from
the client when EAP authentication is requested. If SGW is acting
as pass-through between client and backend authentication server
(e.g. RADIUS), that server will typically start EAP session from
requesting EAP Identity anyway, so the ID Payload received
from the client becomes useless.
One such case might be when using Raw public key authentication, i.e.
in which case the ID is not really in the ID payload, but the public
key is the identity instead. If this is the reason why you say SHOULD,
then we should mention it here.
This is another example when ID_NULL could be used with non-NULL
authentication.
The section 2.3, I do not think there is ever reason to do liveness
check for all other IKE SAs using null authentication. There is
already normal inactivity based liveness checks, so that will take
care of the SAs already, there is nothing we need to do when we
receive INITIAL_CONTACT for some other IP address. What we can do that
if we do receive INITIAL_CONTACT from same IP-address we already have
IKE SA, we could do liveness check for that SA, as that is the most
common case.
The intent was to hint to implementers, that the event of creating
new unauthenticated IKE SA MAY be considered as a trigger for
liveness check procedure on inactive unauthenticated SAs. There is
no requirement that this check be immediately done on all the SAs.
But without such advise naive implementation may ends up
having a lot of stale IKE SAs (for example, if it performs
liveness check only if it needs to send data over SA).
I.e. device creates anonymous IKE SA with server, then device is
restarted, and it creates new IKE SA and now it will send
INITIAL_CONTACT as it does not have any SAs with server. Most likely
those connections have same IP-address, thus to clean up state, it is
Not necessary. Depending on the ISP the client may get new IP address.
enough to just do liveness check for old IKE SA from the same
IP-address. We cannot just remove it as the IP-address might be the
address of the NAT box.
It is not enough to check only SAs with same IP-address.
However, as I've written above, there is no need to
immediately perform liveness check on all SAs.
The event of creating new unauthenticated IKE SA is just a hint,
that some of other such SAs might become stale and
they need to be checked (no rush though).
It is implementation dependant how this check is done -
implementations may check all the SAs if there are
a handfull of them, check first SAs with the same IP
address and let the other to be checked on a time-based basis,
or ignore this event at all and rely on usual regular checking.
I don't think the document should mandate such things.
Also if the device sent some other ID than ID_NULL, we could again do
liveness check for those IKE SAs which have same ID than the new
The -01 version of the draft recommended doing so.
Do you think it is worth put it back?
connection coming in, but of course you would want to rate limit those
just in case someone makes implementation where everybody uses
Sure.
"[email protected]" or similar as their ID, so everybody has exactly
same ID (doing that would be stupid, but that has never stopped people
to do things).
...
Also limiting un-authenticated IKE sessions this way really restricts
the use cases for this. I would rather says that "If authenticated IKE
sessions are possible between the hosts, then un-authenticated IKE
MUST NOT be used". But even that will restrict some use cases.
I think this wording is too restrictive.
Well, the question is: why do we need NULL auth at all.
If it is intended only for opportunistic security, then yes,
it must only be used if the peers cannot authenticate
themselves. But there are use cases when the user is able
to authenticate himself/herself, but he/she doesn't want
to do it for the particular SA. For example, if I'm an Wikipedia
editor, then I need to be able to authentiacte myself while
I perform edits. But I want to keep anonimity while I read
Wikipedia to prevent tracing back what I'm interested in.
For example some forum site might want to restrict posting of new
comments to authenticated users, but would still want to allow reading
of entries without doing authentication. In such cases the client can
be configured to be able to do both. In normal case the user will
always do un-authenticated connection to read entries, and when he
decides to post a reply or new comment, the software would
automatically create new authenticated IKE SA and do the actual post
through that, even when still at the same time keep the
un-authenticated connection for reading... Btw, in such cases the
connections might use per TCP-flow Child SAs...
Exactly.
--
[email protected]
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
