Subject: [IPsec] Too many new notifications? (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes

From: <[email-masked]>
Date: Wed, 24 Oct 2018 12:59:22 +0000

Hi Valery, all, 

Thank you for raising this comment. 

As a reminder, the current version of the draft defines 4 NEW codes. The rationale is as follows: 

(1) An initiator may request one address/prefix, but the request may be rejected because the requested address family is not supported. Returning UNSUPPORTED_AF helps the initiator to deterministically know the failure cause. An alternate AF, if supported, will be used for subsequent requests.  

(2) An initiator may request addresses for both address families. If only one of the requested address families is supported, an address/prefix and notification code is returned to inform the initiation why only one AF is included in the response. This code may be IP4_ONLY_SUPPORTED or IP6_ONLY_SUPPORTED.   

(3) An initiator may request addresses for both address families but, for policy reasons, only one address/prefix per request can be honored (even if both AFs are supported). For this case, none of the previous codes is appropriate. A new code is defined to cover this case: SINGLE_AF_SUPPORTED. 

Can you please indicate which of these codes you think is not required? Thank you.

Cheers,
Med  

> -----Message d'origine-----
> De : IPsec [mailto:[email-masked]] De la part de Valery Smyslov
> Envoyé : mercredi 17 octobre 2018 08:59
> À : 'Tero Kivinen'; [email-masked]
> Objet : Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-
> ipv4-codes
> 
> Hi,
> 
> after reading the draft's introduction, I think the problem described
> is real. So I support adoption of this draft.
> 
> That said, it seems that the current draft solves the problem in
> suboptimal way (too many new notifications defined), but that
> can be definitely discussed in the WG. And yes, I'm ready to
> review the draft.
> 
> Regards,
> Valery.
> 
> > Our new charter has been approved and that includes item:
> >
> >     RFC7296 defines a generic notification code that is related to a
> >     failure to handle an internal address failure. That code does not
> >     explicitly allow an initiator to determine why a given address
> >     family is not assigned, nor whether it should try using another
> >     address family. The Working Group will specify a set of more
> >     specific notification codes that will provide sufficient
> >     information to the IKEv2 initiator about the encountered failure.
> >     A possible starting pointing is
> >     draft-boucadair-ipsecme-ipv6-ipv4-codes.
> >
> > So this email will start one week long WG adoptation call for that
> > document [1] for WG adoptation.
> >
> > Send your comments to this list before the 2018-10-21.
> >
> > [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-
> codes/
> > --
> > [email-masked]
> >
> > _______________________________________________
> > IPsec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 25 Oct 2018 10:32:26 +0300

Hi Med,

> (1) An initiator may request one address/prefix, but the request may be rejected because the requested
> address family is not supported. Returning UNSUPPORTED_AF helps the initiator to deterministically know the
> failure cause. An alternate AF, if supported, will be used for subsequent requests.
> 
> (2) An initiator may request addresses for both address families. If only one of the requested address families
> is supported, an address/prefix and notification code is returned to inform the initiation why only one AF is
> included in the response. This code may be IP4_ONLY_SUPPORTED or IP6_ONLY_SUPPORTED.
> 
> (3) An initiator may request addresses for both address families but, for policy reasons, only one
> address/prefix per request can be honored (even if both AFs are supported). For this case, none of the
> previous codes is appropriate. A new code is defined to cover this case: SINGLE_AF_SUPPORTED.
> 

Unless I missed something, I believe you can get all the needed functionality with a single new notification
SUPPORTED_AFS, with a data containing information which AFs are supported (say a single octet per AF).
In your first three use cases the assignment would not be done and the responder would return this notification 
with the data filled in accordingly. 

The 4th use case is a bit trickier. When the initiator requested both AFs, the responder would return IP of only one 
(any of requested) AF assigned and again the notification SUPPORTED_AFS indicating whic AFs are supported.
The initiator could deduce that a second request is needed to get address from the other AF. 

Note also, that your notifications are error-type notifications. I'd rather define status type notification (like SUPPORTED_AFS).
The problem with error type notifications is that if the initiator doesn't understand it (e.g. an old implementation), it will
tear down IKE SA, because it assumes that the request has failed entirely (Section 3.10.1 of RFC7296). 
This will complicate the deployment of your extension.

Regards,
Valery.

---

From: <[email-masked]>
Date: Thu, 25 Oct 2018 12:58:00 +0000

Hi Valery, 

Please see inline. 

Cheers,
Med

> De : Valery Smyslov [mailto:[email-masked]]
> Envoyé : jeudi 25 octobre 2018 09:32
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Objet : RE: Too many new notifications? (was RE: [IPsec] Call for WG
> Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes
> 
> Hi Med,
> 
> > Hi Valery, all,
> >

[Med] Paul has already proposed this, see: https://mailarchive.ietf.org/arch/msg/ipsec/fFr6rKaK4MkICeA5MI9M4xpmxD0. The comment I made at that time is:

Given the available space (47-8191 or 16385-24575), assigning 4 codes is much more simple compared to assigning a type with sub-values. Isn't it?

> The 4th use case is a bit trickier. When the initiator requested both AFs,
> the responder would return IP of only one

[Med] That would work if we go with sub-values. Given the available space, is it really worth to go down to fields and sub-fields?

> Note also, that your notifications are error-type notifications. I'd rather
> define status type notification (like SUPPORTED_AFS).

[Med] Good point. Will consider this.

> The problem with error type notifications is that if the initiator doesn't
> understand it (e.g. an old implementation), it will

[Med] Thank you.