Re-, We can always speculate about how this will/should be implemented/deployed, but I’m afraid that this won’t be ideal as we would expect. Unfortunately, the wire-format create more troubles than it solves for this specific case.
Avoiding adherence with the underlying discovery library while simplifying provisioning operations were IMO why I was for the representation mode. But, I’m not reopening that. I just want to explore if we can simplify the maintenance of the protocol. Thanks. Cheers, Med De : IPsec <ipsec-boun...@ietf.org> De la part de Ben Schwartz Envoyé : jeudi 5 octobre 2023 15:50 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; Tommy Pauly <tpa...@apple.com>; Paul Wouters <p...@nohats.ca> Cc : 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) In general, IKE and DHCP CPEs shouldn't be manually configured with DNS SvcParams. These SvcParams are adjustable metadata under the control of the DNS server operator, which may change its configuration over time (adding or removing protocols and endpoints, etc.). Instead, the CPE should securely fetch the SvcParams periodically from the DNS operator. If manual configuration in human-readable form is necessary, the CPE should embed a completely standard SvcParams implementation, exactly as used in a DNS server. Requiring a special SvcParams implementation with IKE/DNR-specific features (like a special set of keys) seems likely to make updates slower, not faster. --Ben Schwartz ________________________________ From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Sent: Thursday, October 5, 2023 9:36 AM To: Ben Schwartz <bem...@meta.com<mailto:bem...@meta.com>>; Tommy Pauly <tpa...@apple.com<mailto:tpa...@apple.com>>; Paul Wouters <p...@nohats.ca<mailto:p...@nohats.ca>> Cc: ipsec@ietf.org<mailto:ipsec@ietf.org> <ipsec@ietf.org<mailto:ipsec@ietf.org>>; Valery Smyslov <s...@elvis.ru<mailto:s...@elvis.ru>>; ipsecme-...@ietf.org<mailto:ipsecme-...@ietf.org> <ipsecme-...@ietf.org<mailto:ipsecme-...@ietf.org>>; ipsecme-cha...@ietf.org<mailto:ipsecme-cha...@ietf.org> <ipsecme-cha...@ietf.org<mailto:ipsecme-cha...@ietf.org>>; Dan Wing <d...@danwing.org<mailto:d...@danwing.org>>; Tirumaleswar Reddy <kond...@gmail.com<mailto:kond...@gmail.com>> Subject: RE: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 <draft-ietf-ipsecme-add-ike-14> for your review) 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 ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd 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 <bem...@meta.com<mailto:bem...@meta.com>> Envoyé : jeudi 5 octobre 2023 15:21 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; Tommy Pauly <tpa...@apple.com<mailto:tpa...@apple.com>>; Paul Wouters <p...@nohats.ca<mailto:p...@nohats.ca>> Cc : ipsec@ietf.org<mailto:ipsec@ietf.org>; Valery Smyslov <s...@elvis.ru<mailto:s...@elvis.ru>>; ipsecme-...@ietf.org<mailto:ipsecme-...@ietf.org>; ipsecme-cha...@ietf.org<mailto:ipsecme-cha...@ietf.org>; Dan Wing <d...@danwing.org<mailto:d...@danwing.org>>; Tirumaleswar Reddy <kond...@gmail.com<mailto:kond...@gmail.com>> 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 <ipsec-boun...@ietf.org<mailto:ipsec-boun...@ietf.org>> on behalf of mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Sent: Thursday, October 5, 2023 2:46 AM To: Tommy Pauly <tpa...@apple.com<mailto:tpa...@apple.com>>; Paul Wouters <p...@nohats.ca<mailto:p...@nohats.ca>> Cc: ipsec@ietf.org<mailto:ipsec@ietf.org> <ipsec@ietf.org<mailto:ipsec@ietf.org>>; Valery Smyslov <s...@elvis.ru<mailto:s...@elvis.ru>>; ipsecme-...@ietf.org<mailto:ipsecme-...@ietf.org> <ipsecme-...@ietf.org<mailto:ipsecme-...@ietf.org>>; ipsecme-cha...@ietf.org<mailto:ipsecme-cha...@ietf.org> <ipsecme-cha...@ietf.org<mailto:ipsecme-cha...@ietf.org>>; Dan Wing <d...@danwing.org<mailto:d...@danwing.org>>; Tirumaleswar Reddy <kond...@gmail.com<mailto:kond...@gmail.com>> 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 <tpa...@apple.com<mailto:tpa...@apple.com>> > Envoyé : jeudi 5 octobre 2023 04:44 > À : Paul Wouters <p...@nohats.ca<mailto:p...@nohats.ca>> > Cc : BOUCADAIR Mohamed INNOV/NET > <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; > ipsec@ietf.org<mailto:ipsec@ietf.org>; Valery Smyslov > <s...@elvis.ru<mailto:s...@elvis.ru>>; > ipsecme-...@ietf.org<mailto:ipsecme-...@ietf.org>; > ipsecme-cha...@ietf.org<mailto:ipsecme-cha...@ietf.org>; Dan Wing > <d...@danwing.org<mailto:d...@danwing.org>>; Tirumaleswar > Reddy <kond...@gmail.com<mailto: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<mailto: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<mailto: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://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 IPsec@ietf.org<mailto:IPsec@ietf.org> 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. ____________________________________________________________________________________________________________ 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
