Re: [IPsec] [***SPAM***] RE: SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 <draft-ietf-ipsecme-add-ike-14> for your review)

[Valery Smyslov <[e-mail]>]

Hi Med, Tommy, all,

> Hi Tommy, all,
> 
> One comment on this part:
> 
> > the binary format for the parameters, and it doesn’t require the IKE
> > implementation to do any parsing, etc. on that.
> 
> Actually, it should because we have some restriction on params in DNR/IKE. Blindly passing the
> information to DNS libraries may induce some issues, e.g., when IP hints are present but !=IP addresses.

In addition, RFC 8598 specifies that Domain Name is in DNS presentation format.
So, if encrypted DNS is used with Split DNS, then I suspect the parsing will be needed (am I missing something?).

Regards,
Valery.

> For this reason and also to provide guidance for future params that might (not) be suitable for DNR/IKE,
> do you see a value in tagging these in the IANA SVCB registry? See more at:
> https://boucadair.github.io/dnr-svcb-registry/draft-wb-add-svcb-registry-update.html (not published
> yet).
> 
> For server configuration files (including small ones in CPEs) based on human-readable parameters, the
> DHCP/IKE libraries will do the conversion for sending them using the wire format. Making use of new
> svcparams won’t be automatic as we might ideally hope but some effort will be needed to convince
> vendors that new svcparams are useful for DNR/IKE beyond what is included in the DNR/IKE RFCs. The
> proposed update would help in that maintenance front.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Tommy Pauly <[e-mail]>
> > Envoyé : jeudi 5 octobre 2023 04:44
> > À : Paul Wouters <[e-mail]>
> > Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> > [e-mail]; Valery Smyslov <[e-mail]>; [e-mail];
> > [e-mail]; Dan Wing <[e-mail]>; Tirumaleswar
> > Reddy <[e-mail]>
> > Objet : Re: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464
> > <draft-ietf-ipsecme-add-ike-14> for your review)
> >
> > As with DNR, I definitely think we should be using the wire format
> > here (for communicating on the wire). The IKE option here would carry
> > the binary format for the parameters, and it doesn’t require the IKE
> > implementation to do any parsing, etc on that.
> >
> > Since it looks like there’s good consensus on the DNR side in the ADD
> > WG, I think the most important thing to do is ensure the same format
> > is used for IKE as is used elsewhere. For DDR, DNR, and this IKE
> > extension, they should all use the same format, whether the
> > information is in a DNS packet, a DHCP packet, or an IKE packet.
> >
> > Thanks,
> > Tommy
> >
> > > On Oct 4, 2023, at 5:28 AM, Paul Wouters <[e-mail]> wrote:
> > >
> > > As I said over the other side, I prefer presentation format. Here
> > that is even more true than over at the dhcp server because ike
> > daemons (server AND client) tend to not implement dns wire format.
> > >
> > > Presentation format would be to reject this change.
> > >
> > > But whichever is picked, if I am in the rough, do make it the same
> > format for both drafts.
> > >
> > > Paul
> > >
> > > Sent using a virtual keyboard on a phone
> > >
> > >> On Oct 4, 2023, at 06:33, [e-mail] wrote:
> > >>
> > >> Hi all, =
> > >>
> > >>
> > >> This document is already in AUTH48-DONE but still not published yet
> > >> because= of a normative dependency (see more about the cluster at
> > >>
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > >> .rfc-
> > %2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C9255f776e6cc
> > >>
> > 4c03710d08dbc54d09a2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> > >>
> > 320706888240742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > >>
> > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=j1S53uWVH
> > >> CJoqPS%2BIWoKaFJRUjaz1zC1k2h1FKLEAoQ%3D&reserved=0=
> > >> editor.org/auth48/C461).
> > >>
> > >> A late issue was raised about the encoding of the service
> > parameters
> > >> (repre= sentation format vs wire format). A summary can be found
> > at:
> > >> https://mailar=
> > chive.ietf.org/arch/msg/add/qU_TaosKNhojs3h3ojUb0B_bpXg/.
> > >>
> > >> In order to be consistent with the consensus in ADD, I suggest we
> > >> update RF= C-to-be 9464 as follows: =
> > >>
> > >>
> > >> OLD:
> > >>  Service Parameters (SvcParams) (variable) -  Specifies a set of
> > >>     service parameters that are encoded following the rules in
> > >>     Section 2.1 of [RFC9460].  =
> > >>
> > >>
> > >> NEW:
> > >>  Service Parameters (SvcParams) (variable) -  Specifies a set of
> > >>     service parameters that are encoded following the same rules
> > >>     for encoding SvcParams using the wire format specified
> > >>     in Section 2.2 of [RFC9460]. =
> > >>
> > >>
> > >> The text may seem verbose but the intent is to avoid ambiguity and
> > be
> > >> expli= cit about which part of Section 2.2 of [RFC9460].
> > >>
> > >> Unless we hear an objection by the end of the week, we will request
> > >> the RFC= Editor to make this change. =
> > >>
> > >>
> > >> Cheers,
> > >> Med
> > >>
> ______________________________________________________________________________________
> ______________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne
> doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be
> protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its
> attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or
> falsified.
> Thank you.