Hi Ben, The ossification is what we wanted to avoid with passing the representation format at the first place. I see that risk now with the wire format and I’m really concerned about that, especially for CPEs :-(
We can’t impose that the configuration parameters are always supplied as binary blobs. Cheers, Med De : Ben Schwartz <[email protected]> Envoyé : jeudi 5 octobre 2023 15:21 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; Tommy Pauly <[email protected]>; Paul Wouters <[email protected]> Cc : [email protected]; Valery Smyslov <[email protected]>; [email protected]; [email protected]; Dan Wing <[email protected]>; Tirumaleswar Reddy <[email protected]> Objet : Re: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 <draft-ietf-ipsecme-add-ike-14> for your review) I think adding columns to the registry is likely to have the opposite effect: implementers will feel that they are required to use a special implementation of SvcParams, rather than simply passing the blob around. This will create severe ossification: DNS servers won't be able to activate new SvcParamKeys until the CPE firmware's special DNR-SvcParams code is updated with a new feature, which may never happen at all. Instead, clients should be instructed to ignore any keys that they don't intend to use (as is always the case in SVCB), and IKE/DNR servers can memcpy their responses directly from the SVCB RDATA. --Ben Schwartz [1] https://www.ietf.org/archive/id/draft-ietf-add-dnr-16.html#section-3.1.8 ________________________________ From: IPsec <[email protected]<mailto:[email protected]>> on behalf of [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Thursday, October 5, 2023 2:46 AM To: Tommy Pauly <[email protected]<mailto:[email protected]>>; Paul Wouters <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Valery Smyslov <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Dan Wing <[email protected]<mailto:[email protected]>>; Tirumaleswar Reddy <[email protected]<mailto:[email protected]>> Subject: Re: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 <draft-ietf-ipsecme-add-ike-14> for your review) !-------------------------------------------------------------------| This Message Is From an External Sender |-------------------------------------------------------------------! 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. 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 <[email protected]<mailto:[email protected]>> > Envoyé : jeudi 5 octobre 2023 04:44 > À : Paul Wouters <[email protected]<mailto:[email protected]>> > Cc : BOUCADAIR Mohamed INNOV/NET > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; Valery Smyslov > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; Dan Wing > <[email protected]<mailto:[email protected]>>; Tirumaleswar > Reddy <[email protected]<mailto:[email protected]>> > 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 > > <[email protected]<mailto:[email protected]>> 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, > >> [email protected]<mailto:[email protected]> 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://www<https://www/> > >> .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. _______________________________________________ IPsec mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec ____________________________________________________________________________________________________________ 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.
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
