Subject: [IPsec] NO_ADDITIONAL_SAS text in Conformance Requirements

From: David Wierbowski <[email-masked]>
Date: Tue, 6 Jan 2009 10:17:40 -0500

Section 4 of RFC 4306 (and draft-ietf-ipsecme-ikev2bis-01.txt) contains the
following text:

A minimal implementation MAY support the CREATE_CHILD_SA exchange only in
so far as to recognize requests and reject them with a Notify payload of
type NO_ADDITIONAL_SAS.  A minimal implementation need not be able to
initiate CREATE_CHILD_SA or INFORMATIONAL exchanges.  When an SA  expires
(based on locally configured values of either lifetime or octets passed),
and implementation MAY either try to renew it with a CREATE_CHILD_SA
exchange or it MAY delete (close) the old SA and create a new one.  If the
responder rejects the CREATE_CHILD_SA request with a NO_ADDITIONAL_SAS
notification, the implementation MUST be capable of instead deleting the
old SA and creating a new one.

I have a few questions concerning the last sentence in that text:

1) Does this sentence only apply to CREATE_CHILD_SA exchanges used to rekey
an existing SA (i.e. an attempt to rekey either an IKE SA or Child SA and
not an attempt to create a new child SA)?

2) Assume the CREATE_CHILD_SA exchange that resulted in the
NO_ADDITIONAL_SAS notification was intended to rekey an existing child SA.
Does "old SA" refer to the existing child SA that was being rekeyed or the
IKE SA that was used when the NO_ADDITIONAL_SAS notify was returned?

3) What action should be taken if the NO_ADDITIONAL_SAS notify is received
in a CREATE_CHILD_SA exchange intended to create a new child SA rather than
rekeying an existing SA?

Dave Wierbowski

z/OS Comm Server Developer

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 7 Jan 2009 14:55:25 +0200

> not an attempt to create a new child SA)?

No. It is clear that minimal implementation can return that error also
for attemtps to create a new child SA. The text saying "MAY support
the CREATE_CHILD_SA exchange only so far as to recognize requests and
reject them" clearly is covers any CREATE_CHILD_SA exchanges, i.e.
both rekeys and creating new child SA. 

> IKE SA that was used when the NO_ADDITIONAL_SAS notify was returned?

I would say either. There might be implementations who do not support
CREATE_CHILD_SA exchange at all, i.e. they will always return
NO_ADDITIONAL_SAS for it, regardless whether it is rekey or creation
of new SA. In those applications the rekey CREATE_CHILD_SA might
result NO_ADDITIONAL_SAS and then after deleting the IPsec SA, and
trying CREATE_CHILD_SA to create new child SA might still result
NO_ADDITIONAL_SAS and in that case the only option left is to remove
the IKE SA and start over.

There might also be implementations who do support CREATE_CHILD_SA but
only support exactly one IPsec SA, and that case the creation of child
SA might succeed after the rekey CREATE_CHILD_SA was rejected with
NO_ADDITIONAL_SAS. I.e. there the rekey CREATE_CHILD_SA will be
rejected with NO_ADDITIONAL_SAS but after deleting the old child SA,
new CREATE_CHILD_SA for creating new child SA might still succeed.

The current text is not really clear whether we want to support both
of those options, or whether only the first option is to be supported
(i.e. where minimal implmenetation does not support CREATE_CHILD_SA at
all, except recognize it and return NO_ADDITIONAL_SAS error). 

> in a CREATE_CHILD_SA exchange intended to create a new child SA rather than

Good question. If there is still child SAs on the same IKE SA,  then
you could try to deleting those first, and then retrying. If there is
no child SAs with the current IKE SA, and you get NO_ADDITIONAL_SAS as
error telling no more child SAs can be created, then you need to
delete the whole IKE SA and start over. That behavior would be
complient with both of the cases I showed above.

If you only want to cover first case then you can always delete IKE SA
and start over when you get NO_ADDITIONAL_SAS.

If the NO_ADDITIONAL_SAS was received during IKE_AUTH, that is
completely different matter, and that is not defined in the current
documents. My suggestion there was that if you receive
NO_ADDITIONAL_SAS during IKE_AUTH, you put that IKE SA on hold for
60-120 seconds (i.e. do not trigger new exchanges for that IKE SA, but
do process request from other end), and after that you remove that
hold, and for the next packet that would trigger new SA you try
CREATE_CHILD_SA and see if it works now. If it does not work now, you
follow rules specified above, i.e. as you do not have child SAs and
you receive NO_ADDITIONAL_SAS, you delete IKE SA and start over. This
would be matching what I suggested for the redirect case or any other
case when the server is out of resources to create new child SAs.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec