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 <tpa...@apple.com> > > Envoyé : jeudi 5 octobre 2023 04:44 > > À : Paul Wouters <p...@nohats.ca> > > Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > > ipsec@ietf.org; Valery Smyslov <s...@elvis.ru>; ipsecme-...@ietf.org; > > ipsecme-cha...@ietf.org; Dan Wing <d...@danwing.org>; Tirumaleswar > > Reddy <kond...@gmail.com> > > 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 <p...@nohats.ca> 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, mohamed.boucad...@orange.com 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
