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]> > Envoyé : jeudi 5 octobre 2023 04:44 > À : Paul Wouters <[email protected]> > Cc : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [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) > > 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]> 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] 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. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
