Subject: [IPsec] #56: Address and config values lifetime

From: Yaron Sheffer <[email-masked]>
Date: Sun, 7 Dec 2008 17:09:22 +0200

Yaron: 2.19: INTERNAL_ADDRESS_EXPIRY is gone, but shouldn't we specify what
the gateway should do if the address lease expires? On a related note, the
section does not specify the lifetime of the configuration values, i.e.
should they be renewed by the next IKE SA rekey, or reauthentication, or
never?

Room: [A gateway] SHOULD keep addresses alive when possible.  What if not
possible (e.g., DHCP refuses to renew address, or changes it)?  May need to
actually delete the IKE SA in order to get the client to notice that it has
a problem - this also cleans up all the associated state (e.g.,
traffic selectors may not survive).  Might want to introduce a notification
that the SA is about to be deleted (may also apply to an EAP authentication
that has to be renewed every x hours).  Clients
already have to expect IKE SA to be torn down at any time for any reason.
 
Yaron: I read all the above as saying that the lifetime of the configuration
params is identical to the IKE SA's lifetime. Let's clarify it.

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Jimmy Zhang <[email-masked]>
Date: Tue, 16 Dec 2008 12:57:55 -0800

Hi, All,

When USE_TRANSPORT_MODE notification is received along with the SA payload, current spec reads,
   If the responder declines the request, the Child SA will be
   established in tunnel mode.  If this is unacceptable to the
   initiator, the initiator MUST delete the SA."

IPCOMP_SUPPORTED notification is similar to USE_TRANSPORT_MODE, they both are actually part of the proposal but are sent in notification payload. However, the RFC and IKEv2bis don't cover what if the responder doesn't accept any of the proposed compression algorithms. The current spec reads,
   --The response MAY indicate acceptance of a single compression
   algorithm with a Notify payload of type IPCOMP_SUPPORTED.
   --A message accepting an SA may contain at most one (compression
   algorithm).
   --Implementations of this specification MUST NOT accept an
   IPComp algorithm that was not proposed, MUST NOT accept more
   than one, and MUST NOT compress using an algorithm other than
   one proposed and  accepted in the setup of the Child SA".

But what if absolutely no algorithm is acceptable? The first response is maybe to add something similar to USE_TRANSPORT_MODE for consistency reason,
   If the responder declines all the requested compression
   algorithms, the Child SA will be established without
   compression. If this is unacceptable to the initiator,
   the initiator MUST delete the SA.

This will cause another and maybe bigger problem, what if the initiator proposes algorithm A, but the responder only supports and requires algorithm B in its policy? In this case, what the responder really wants is a NO_PROPOSAL_CHOSEN response, not something against its own policy (its own policy requires algorithm B, not NONE).

Thus I think we do need some clarification on whether it is legible to send back NO_PROPOSAL_CHOSEN just because of the content in Notification payload (instead of Proposal payload)? I think it legible. Responder has its own decision to reply with NO_PROPOSAL_CHOSEN to unwanted USE_TRANSPORT_MODE or IPCOMP_SUPPORTED notifications.  We don't prevent responder to do that in current spec anyway, but a clarification will surely help, especially to the above mentioned IPCOMP_SUPPORTED response when no algorithm is acceptable.

Thanks,
Jimmy Zhang

________________________________
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information which is protected from disclosure. Any unauthorized review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please contact the sender by reply email or at (408) 399-3500 and destroy all copies of the original message.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 17 Dec 2008 14:24:59 +0200

Jimmy Zhang writes:
> IPCOMP_SUPPORTED notification is similar to USE_TRANSPORT_MODE, they
> both are actually part of the proposal but are sent in notification
> payload. However, the RFC and IKEv2bis don't cover what if the
> responder doesn't accept any of the proposed compression algorithms.
> The current spec reads,

I think it is clear that if responder finds that none of the proposals
is acceptable it will send NO_PROPOSAL_CHOSEN error. This does not
care where the policy was wrong, it can be encryption algorithms, it
can be tunnel vs transport mode (i.e. if initiator didn't offer
transport mode and responder REQUIRED transport mode it will send
NO_PROPOSAL_CHOSEN back) or whether it was IPcomp algorithms which do
not match.

The text about the transport mode is when the initiator does not allow
the choise responder did, i.e. it does not allow tunnel mode to be
selectede by responder because it REQUIRES transport mode. As it
cannot send any error messages back at that point anymore, only thing
it can do is to delete the IPsec SA.

It can do exactly same thing with IPcomp, as this does not require any
special signaling there. I.e. if initiator required IPcomp and
responder didn't allow IPcomp and didn't respond with IPCOMP_SUPPORTED
notify at all (i.e. to indicate it does not support IPcomp), then
initiator has now two options

1) Use the IPsec SA without IPcomp
2) Delete the IPsec SA and fail the whole negotiation

If the SA without IPcomp is against his policy he will select option
2, and then fail the connection to the responder. 

> But what if absolutely no algorithm is acceptable? The first
> response is maybe to add something similar to USE_TRANSPORT_MODE for
> consistency reason,
>

This is ok to add there, but as initiator is allowed to do that in all
cases anyways, I do not really need any reason to add that kind of
text.

Actually adding such text might make implementations to implement
policies which might not be that useful, i.e "MUST do IPcomp". That
kind of policy is not really useful, as if the responder supports
IPcomp and configured to allow it, the responder will enable IPcomp.
If responder does not support IPcomp or is not configured to allow it,
then that will just cause the case where two peers cannot communicate.

It might make it easier to detect configuration errors as parameters
MUST match exactly in both ends, but again makes IPsec configuration
more difficult as parameters must match exactly.

It would be better to use policies which only set minimum level of
requirements and allow negotiation of parameters, than to use policies
which set parameters exactly and require them to be exactly same in
both ends.

> This will cause another and maybe bigger problem, what if the
> initiator proposes algorithm A, but the responder only supports and
> requires algorithm B in its policy? In this case, what the responder
> really wants is a NO_PROPOSAL_CHOSEN response, not something against
> its own policy (its own policy requires algorithm B, not NONE).

Responder is always allowed to send NO_PROPOSAL_CHOSEN and if it
really requires algorithm B it will send NO_PROPOSAL_CHOSEN and no
IPsec SA can be created between the peers, until either ends
configuration has been changed.

> Thus I think we do need some clarification on whether it is legible
> to send back NO_PROPOSAL_CHOSEN just because of the content in
> Notification payload (instead of Proposal payload)? I think it
> legible.

As matching offered policy against your own local policy is mostly
implementation details, you can send NO_PROPOSAL_CHOSEN whenever the
offered proposal does not match your policy.

We at least do send that in case the transport mode is required by
responder, but initiator didn't offer it. We do not have option to
require IPcomp (they are always optional) so IPcomp mismatches do not
cause us to send NO_PROPOSAL_CHOSEN. 

> Responder has its own decision to reply with
> NO_PROPOSAL_CHOSEN to unwanted USE_TRANSPORT_MODE or
> IPCOMP_SUPPORTED notifications.  We don't prevent responder to do
> that in current spec anyway, but a clarification will surely help,
> especially to the above mentioned IPCOMP_SUPPORTED response when no
> algorithm is acceptable. 

We could add some more text about that, but as it mostly clarifies
something that responder can already do anyways, I am not sure if it
is really needed (but I am not against adding such text).
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Jimmy Zhang <[email-masked]>
Date: Wed, 17 Dec 2008 15:07:36 -0800

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Wednesday, December 17, 2008 7:25 AM
> To: Jimmy Zhang
> Cc: IPsecme WG
> Subject: [IPsec] regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED
> notifications
>

This is exactly the area I suggested some clarification. Transport mode and IPcomp negotiation are performed through notification payload in IKEv2, not in SA and Proposal payload. Some implementations (like yours) may treat them as optional parameters because it is a notification anyway, some may still treat them as important as other cryptographic parameters in the Proposal payload, for the latter, they will and they should reply with NO_PROPOSAL_CHOSEN if the mode or IPcomp algorithm doesn't match. IMO, to reply NO_PROPOSEN_CHOSEN against a status notification does need some explicit clarification in order to make it a more formal instead of far-fetched. Current spec only talks about NO_PROPOSAL_CHOSEN in Proposal Payload processing in section 2.7

Thanks,
Jimmy

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 Dec 2008 12:19:23 +0200

Jimmy Zhang writes:
> This is exactly the area I suggested some clarification. Transport
> mode and IPcomp negotiation are performed through notification
> payload in IKEv2, not in SA and Proposal payload. Some
> implementations (like yours) may treat them as optional parameters
> because it is a notification anyway, some may still treat them as
> important as other cryptographic parameters in the Proposal payload,
> for the latter, they will and they should reply with
> NO_PROPOSAL_CHOSEN if the mode or IPcomp algorithm doesn't match.
> IMO, to reply NO_PROPOSEN_CHOSEN against a status notification does
> need some explicit clarification in order to make it a more formal
> instead of far-fetched. Current spec only talks about
> NO_PROPOSAL_CHOSEN in Proposal Payload processing in section 2.7 

Current RFC talks about NO_PROPOSAL_CHOSEN in the 3.10.1 Notify
message types and only says it is returned when "None of the proposed
crypto suites was acceptable.".

Now the question is the IPcomp and Tunnel/Transport mode part of your
crypto suites. The section 1 defines terms "suite" or "cryptographic
suite" as "complete set of algorithms used to protect an SA.", and I
think tunnel/transport mode and even IPcomp are part of the set of
algorithms used to protect an SA.

So using RFC4306 I think it is quiet clear that you MAY send
NO_PROPOSAL_CHOSEN even in those cases.

The ikev2bis draft moved the NO_PROPOSAL_CHOSEN to the section 2.7
which I think didn't clarify the issue, but made it unclear whether
NO_PROPOSAL_CHOSEN can be used for tunnel/transport mode mismatch
and/or IPcomp algorithm mismatch. On the other hand it only says that
you use NO_PROPOSAL_CHOSEN if you cannot select suitable proposal, it
does NOT say you cannot use NO_PROPOSAL_CHOSEN in other cases.

For example section 2.8.1. already uses NO_PROPOSAL_CHOSEN in case
simultaneous child SA exchange to signal "generic" non-fatal error for
create child sa creation.

I think the ikev2bis needs to clarify this, as it was clearer in the
RFC4306, but new version is not so clear anymore.

I would put some more text back to the 3.10.1 NO_PROPOSAL_CHOSEN and
say:

----------------------------------------------------------------------
   NO_PROPOSAL_CHOSEN                       14

       None of the proposed crypto suites was acceptable. This can be
       sent in any case where the offered proposal (including but not
       limited to SA payload values, USE_TRANSPORT_MODE notify,
       IPCOMP_SUPPORTED notify) are not acceptable for the responder.
       This can also be as "generic" Child SA error when Child SA
       cannot be created for some other reason.
       See also Section 2.7.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Jimmy Zhang <[email-masked]>
Date: Thu, 18 Dec 2008 07:12:32 -0800

Thanks and I like your words to IKEv2bis.
Jimmy

> Sent: Thursday, December 18, 2008 5:19 AM
> To: Jimmy Zhang
> Cc: IPsecme WG
> Subject: RE: [IPsec] regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED
> notifications
>
> Jimmy Zhang writes: