Valery Smyslov writes: > 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.
Nope. The IKE ID payloads needs to be used, and the EAP identity reqeuest and respond SHOULD NOT be used (from RFC7296 section 3.16): Note that since IKE passes an indication of initiator identity in the first message in the IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity requests. The initiator MAY, however, respond to such requests if it receives them. Also section 2.16 warns that if EAP Identity is used, there might be mismatch with the ID payloads, and correct one needs to be used for policy lookups: When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity, if different from that in the IDi payload, has to be sent from the AAA server to the IKEv2 responder. > 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). On the other hand if it has enough resources, there is not really a problem having lots of stale IKE SAs. Storing those IKE SAs in the memory does not really increase the power consumption of the device (yes, there might be devices where this might actually be true, and in that case it should most likely use more aggressive cleanup policy). If the device is running out of resources, then it should start doing some cleanup processes (most likely way ahead of when it actually runs out of resources). > > 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. Yes, but very commonly it will get same IP and that is the case we should optimize for. Doing one liveness check for one IP is cheap. Starting to do it for 10000 IKE SAs is expensive... Especially if we have new un-authenticated IKE connections at the rate of 10/sec... (i.e. the average connection time is few hours). > > 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. We do not need to clear out all stale IKE SA from the memory, we need to make sure we optimize and clean up the most likely one. The rest are taken care of by the normal cleanup routines. > 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). I would expect that servers having so many users that liveness checks really matter, will have so many new sessions per second, that this statement is compeltely useless, as you would get this hint several times per second, which means it is useless hint. If you only get new un-authenticate IKE SA every few minutes or so, then you most likely will not have enough stale IKE SAs for them to matter (lets say you have 4 hour lifetime for IKE SAs and new connections every 2 minutes, that will mean you have 120 IKE SA). > 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. I agree. But I think more usefull hint for implementors would be to check the IKE SAs having same IP address than newly created IKE SA, than the current one we have. > > 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? Yes. Especially as the rfc7296 will talk about INITIAL_CONTACT and authenticated identities. When we are talking about un-authenticated identities we should just say that this does not automatically clean up any state, just provide hint that liveness check might be usefull for that IKE SA. > > 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. As I pointed out, I too think it might be too restrictive... but it is better than what we have now there. > 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. Yep. Altough as Paul will point out that wikipedia uses http, so it would be using IKE, but I assume you similar class of services, some of which might be running over UDP etc. How to formulate the text in the draft is different matter. Perhaps If authenticated IKE sessions are possible between the hosts, then un-authenticated IKE SHOULD NOT be used, unless implementations make sure to keep authenticated and un-authenticated IKE sessions separate, and has policy rules to specify when to use which IKE session. Or something like that. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
