'Re: [IPsec] Too many new notifications? (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [IPsec] Too many new notifications? (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-
From:       <mohamed.boucadair () orange ! com>
Date:       2018-10-25 12:58:00
Message-ID: 787AE7BB302AE849A7480A190F8B93302E037A45 () OPEXCLILMA3 ! corporate ! adroot ! infra ! ftgroup
[Download RAW message or body]

Hi Valery, =

Please see inline. =

Cheers,
Med

> -----Message d'origine-----
> De=A0: Valery Smyslov [mailto:smyslov.ietf@gmail.com]
> Envoy=E9=A0: jeudi 25 octobre 2018 09:32
> =C0=A0: BOUCADAIR Mohamed TGI/OLN; ipsec@ietf.org
> Objet=A0: RE: Too many new notifications? (was RE: [IPsec] Call for WG
> Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes
> =

> Hi Med,
> =

> > 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 subseque=
nt
> requests.
> >
> > (2) An initiator may request addresses for both address families. If on=
ly
> one of the requested address families
> > is supported, an address/prefix and notification code is returned to in=
form
> 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, f=
or
> policy reasons, only one
> > address/prefix per request can be honored (even if both AFs are support=
ed).
> 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.
> =

> Unless I missed something, I believe you can get all the needed functiona=
lity
> 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.
> =

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

Given the available space (47-8191 or 16385-24575), assigning 4 codes is mu=
ch 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
> (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.
> =

[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 rath=
er
> 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
> 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.

[Med] Thank you. =

> =

> Regards,
> Valery.
> =

> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de Valery Smy=
slov
> > > Envoy=E9=A0: mercredi 17 octobre 2018 08:59
> > > =C0=A0: 'Tero Kivinen'; ipsec@ietf.org
> > > Objet=A0: Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipse=
cme-
> 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 n=
ot
> > > >     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 failur=
e.
> > > >     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-i=
pv4-
> > > codes/
> > > > --
> > > > kivinen@iki.fi
> > > >
> > > > _______________________________________________
> > > > IPsec mailing list
> > > > IPsec@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/ipsec
> > >
> > > _______________________________________________
> > > IPsec mailing list
> > > IPsec@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread] 