Hi all.
Yet another batch of issues that we wish to close.
Issue #140 - No SPD entry for transport mode
============================================
Section 2.23.1: If the responder doesn't find SPD entry for transport mode with
the modified traffic selectors, and does a lookup with the original selectors,
if it finds an entry for transport mode, can it use it? (And would that screw
up the initiator processing of the reply? Unfortunately, this question is
relevant for RFC 5555...)
Pasi and Tero had a discussion about this on list. Apparently, the strange
scenario is with a multi-homed host, where IKE went through one interface,
while IPsec went through another, so that IKE was NATted, but IPsec was not.
Tero thinks such a case would never work, while Pasi thinks it is allowed by
RFC 4301 (though probably won't work with most implementations)
I think the scenario is so far-fetched (because discovering NAT in IKE makes
IPsec UDP-encapsulated), that we can afford to ignore it for now. If it comes
up in real life, somebody will get the opportunity to write an extension
document.
Unless people feel strongly otherwise, I suggest we close this issue in a
couple of days without text changes.
Issue #148 - Historical Cookie Discussion
=========================================
In 2.6, first paragraph: the historical discussion going back to the previous
century is very confusing to a newcomer: instead of saying what a cookie is, we
tell a story. I suggest to remove this discussion or move it to the end of the
section.
Can we separate the cookie discussion into its own subsection? For two reasons:
it is an implementation hint, rather than a specification (as opposed to the
normative text on SPIs earlier in 2.6); and it is not very important, given the
prevalence of DDos.
Both me and Pasi said we were not confused by this, and nobody else chimed in.
I agree with Pasi - the path of least resistance is to leave it as is.
Issue #150 - What happens if the peer receives TEMPORARY_FAILURE and ...
========================================================================
2.8.2: we should add a sentence on what happens if the peer receives
TEMPORARY_FAILURE and does not understand it (because it's new to this spec).
Keith explained how this issue came about. In any case, I think this can be
closed with an addition of the following short paragraph:
Support of the TEMPORARY_FAILURE notification is not negotiated, so older
peers may get it. In that case, they will treat it as any other unknown
error notification and fail the exchange. Since the other peer has
already rekeyed the exchange, this does not have any ill effects.
Again, if you object to this, please speak up now.
Issue #151 - Explicit calculation of AUTH
=========================================
2.16: it would be useful if we added the explicit calculation of AUTH. For
example, is the padding string required for EAP as well? There are two cases,
with MSK and with SK_pi+SK_pr.
No discussion for this issue.
I suggest the following paragraph should be added to section 2.15, right after
the explicit AUTH calculation (added here for clarity):
For the initiator:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<InitiatorSignedOctets>)
For the responder:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<ResponderSignedOctets>)
For EAP authentication (see [Section 2.16]), there are two cases. If the
EAP method is key-generating, substitute "MSK" for "Shared Secret" above.
For non-key-generating methods, use SK_pi and SK_pr for the two formulas
above respectively.
Would this satisfy everybody?
Issue #152 - EAP failure and acknowledgement
============================================
2.16: if the responder sends an EAP Failure, is this IKE message acknowledged
by the initiator?
Yaron & Tero discussed this a bit, and the conclusion was to change the text in
2.21 as follows
Before:
Only authentication failures (AUTHENTICATION_FAILED) and malformed
messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without
requiring an explicit INFORMATIONAL exchange carrying a DELETE
payload. Other error conditions MAY require such an exchange if
policy dictates that this is needed.
After:
Only authentication failures (AUTHENTICATION_FAILED and EAP failure) and
Malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE SA
Without requiring an explicit INFORMATIONAL exchange carrying a DELETE
payload. Other error conditions MAY require such an exchange if
policy dictates that this is needed.
And also add at the end of 2.16:
If the exchange is terminated with EAP Failure, an AUTHENTICATION_FAILED
notification is not sent.
Unless anybody objects, we will make these changes in the draft.
Yoav
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
