[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 <draft-ietf-ipsecme-add-ike-14> for y
From: mohamed.boucadair () orange ! com
Date: 2023-10-05 14:17:57
Message-ID: DU2PR02MB10160A93186EED3BF6379EE0788CAA () DU2PR02MB10160 ! eurprd02 ! prod ! outlook ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
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-bounces@ietf.org> De la part de Ben Schwartz
Envoyé : jeudi 5 octobre 2023 15:50
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Tommy Pauly \
<tpauly@apple.com>; Paul Wouters <paul@nohats.ca> Cc : ipsec@ietf.org; Valery Smyslov \
<svan@elvis.ru>; ipsecme-ads@ietf.org; ipsecme-chairs@ietf.org; Dan Wing \
<dan@danwing.org>; Tirumaleswar Reddy <kondtir@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.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> \
<mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Sent: Thursday, October 5, 2023 9:36 AM
To: Ben Schwartz <bemasc@meta.com<mailto:bemasc@meta.com>>; Tommy Pauly \
<tpauly@apple.com<mailto:tpauly@apple.com>>; Paul Wouters \
<paul@nohats.ca<mailto:paul@nohats.ca>>
Cc: ipsec@ietf.org<mailto:ipsec@ietf.org> <ipsec@ietf.org<mailto:ipsec@ietf.org>>; \
Valery Smyslov <svan@elvis.ru<mailto:svan@elvis.ru>>; \
ipsecme-ads@ietf.org<mailto:ipsecme-ads@ietf.org> \
<ipsecme-ads@ietf.org<mailto:ipsecme-ads@ietf.org>>; \
ipsecme-chairs@ietf.org<mailto:ipsecme-chairs@ietf.org> \
<ipsecme-chairs@ietf.org<mailto:ipsecme-chairs@ietf.org>>; Dan Wing \
<dan@danwing.org<mailto:dan@danwing.org>>; Tirumaleswar Reddy \
<kondtir@gmail.com<mailto:kondtir@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 <bemasc@meta.com<mailto:bemasc@meta.com>>
Envoyé : jeudi 5 octobre 2023 15:21
À : BOUCADAIR Mohamed INNOV/NET \
<mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>; Tommy Pauly \
<tpauly@apple.com<mailto:tpauly@apple.com>>; Paul Wouters \
<paul@nohats.ca<mailto:paul@nohats.ca>> Cc : ipsec@ietf.org<mailto:ipsec@ietf.org>; \
Valery Smyslov <svan@elvis.ru<mailto:svan@elvis.ru>>; \
ipsecme-ads@ietf.org<mailto:ipsecme-ads@ietf.org>; \
ipsecme-chairs@ietf.org<mailto:ipsecme-chairs@ietf.org>; Dan Wing \
<dan@danwing.org<mailto:dan@danwing.org>>; Tirumaleswar Reddy \
<kondtir@gmail.com<mailto:kondtir@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-bounces@ietf.org<mailto:ipsec-bounces@ietf.org>> on behalf of \
mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> \
<mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Sent: Thursday, October 5, 2023 2:46 AM
To: Tommy Pauly <tpauly@apple.com<mailto:tpauly@apple.com>>; Paul Wouters \
<paul@nohats.ca<mailto:paul@nohats.ca>>
Cc: ipsec@ietf.org<mailto:ipsec@ietf.org> <ipsec@ietf.org<mailto:ipsec@ietf.org>>; \
Valery Smyslov <svan@elvis.ru<mailto:svan@elvis.ru>>; \
ipsecme-ads@ietf.org<mailto:ipsecme-ads@ietf.org> \
<ipsecme-ads@ietf.org<mailto:ipsecme-ads@ietf.org>>; \
ipsecme-chairs@ietf.org<mailto:ipsecme-chairs@ietf.org> \
<ipsecme-chairs@ietf.org<mailto:ipsecme-chairs@ietf.org>>; Dan Wing \
<dan@danwing.org<mailto:dan@danwing.org>>; Tirumaleswar Reddy \
<kondtir@gmail.com<mailto:kondtir@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 <tpauly@apple.com<mailto:tpauly@apple.com>>
> Envoyé : jeudi 5 octobre 2023 04:44
> À : Paul Wouters <paul@nohats.ca<mailto:paul@nohats.ca>>
> Cc : BOUCADAIR Mohamed INNOV/NET \
> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>; \
> ipsec@ietf.org<mailto:ipsec@ietf.org>; Valery Smyslov \
> <svan@elvis.ru<mailto:svan@elvis.ru>>; \
> ipsecme-ads@ietf.org<mailto:ipsecme-ads@ietf.org>; \
> ipsecme-chairs@ietf.org<mailto:ipsecme-chairs@ietf.org>; Dan Wing \
> <dan@danwing.org<mailto:dan@danwing.org>>; Tirumaleswar Reddy \
> <kondtir@gmail.com<mailto:kondtir@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 \
> > <paul@nohats.ca<mailto:paul@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.boucadair@orange.com<mailto:mohamed.boucadair@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.
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"Préformaté HTML Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New",serif;}
p.xmsonormal, li.xmsonormal, div.xmsonormal
{mso-style-name:x_msonormal;
margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.PrformatHTMLCar
{mso-style-name:"Préformaté HTML Car";
mso-style-priority:99;
mso-style-link:"Préformaté HTML";
font-family:Consolas;}
span.EmailStyle26
{mso-style-type:personal-reply;
font-family:"Courier New",serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="FR" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Courier \
New",serif;mso-fareast-language:EN-US">Re-,<o:p></o:p></span></p> <p \
class="MsoNormal"><span style="font-family:"Courier \
New",serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US" style="font-family:"Courier \
New",serif;mso-fareast-language:EN-US">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. <o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier \
New",serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US" style="font-family:"Courier \
New",serif;mso-fareast-language:EN-US">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.<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US" style="font-family:"Courier \
New",serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US" style="font-family:"Courier \
New",serif;mso-fareast-language:EN-US">Thanks. <o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US" style="font-family:"Courier \
New",serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US" style="font-family:"Courier \
New",serif;mso-fareast-language:EN-US">Cheers,<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US" style="font-family:"Courier \
New",serif;mso-fareast-language:EN-US">Med<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US" style="font-family:"Courier \
New",serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p> <div \
style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"> <div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>De :</b> IPsec <ipsec-bounces@ietf.org> <b>De la \
part de</b> Ben Schwartz<br> <b>Envoyé :</b> jeudi 5 octobre 2023 15:50<br>
<b>À :</b> BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; \
Tommy Pauly <tpauly@apple.com>; Paul Wouters <paul@nohats.ca><br> \
<b>Cc :</b> ipsec@ietf.org; Valery Smyslov <svan@elvis.ru>; \
ipsecme-ads@ietf.org; ipsecme-chairs@ietf.org; Dan Wing <dan@danwing.org>; \
Tirumaleswar Reddy <kondtir@gmail.com><br> <b>Objet :</b> Re: [IPsec] \
SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 \
<draft-ietf-ipsecme-add-ike-14> for your review)<o:p></o:p></p> </div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">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.<o:p></o:p></span></p> </div>
<div>
<p class="MsoNormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">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.<o:p></o:p></span></p> </div>
<div>
<p class="MsoNormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">--Ben \
Schwartz<o:p></o:p></span></p> </div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span \
style="color:black"> <a \
href="mailto:mohamed.boucadair@orange.com">mohamed.boucadair@orange.com</a> <<a \
href="mailto:mohamed.boucadair@orange.com">mohamed.boucadair@orange.com</a>><br> \
<b>Sent:</b> Thursday, October 5, 2023 9:36 AM<br> <b>To:</b> Ben Schwartz <<a \
href="mailto:bemasc@meta.com">bemasc@meta.com</a>>; Tommy Pauly <<a \
href="mailto:tpauly@apple.com">tpauly@apple.com</a>>; Paul Wouters <<a \
href="mailto:paul@nohats.ca">paul@nohats.ca</a>><br> <b>Cc:</b> <a \
href="mailto:ipsec@ietf.org">ipsec@ietf.org</a> <<a \
href="mailto:ipsec@ietf.org">ipsec@ietf.org</a>>; Valery Smyslov <<a \
href="mailto:svan@elvis.ru">svan@elvis.ru</a>>; <a \
href="mailto:ipsecme-ads@ietf.org">ipsecme-ads@ietf.org</a> <<a \
href="mailto:ipsecme-ads@ietf.org">ipsecme-ads@ietf.org</a>>; <a \
href="mailto:ipsecme-chairs@ietf.org">ipsecme-chairs@ietf.org</a> <<a \
href="mailto:ipsecme-chairs@ietf.org">ipsecme-chairs@ietf.org</a>>; Dan Wing \
<<a href="mailto:dan@danwing.org">dan@danwing.org</a>>; Tirumaleswar Reddy \
<<a href="mailto:kondtir@gmail.com">kondtir@gmail.com</a>><br> <b>Subject:</b> \
RE: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 \
<draft-ietf-ipsecme-add-ike-14> for your review)</span> <o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-line-height-alt:.75pt"><span \
style="font-size:1.0pt;color:white">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 <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-line-height-alt:.75pt"><span \
style="font-size:1.0pt;color:white">ZjQcmQRYFpfptBannerStart<o:p></o:p></span></p> \
</div> <div style="border:none;border-top:solid #D9C200 3.0pt;padding:0cm 0cm 0cm \
0cm;display:block!important;text-align:left!important;margin:0px!important;padding:16p \
x!important;border-radius:4px!important;min-width:200px!important;background-color:#F3E496!important;border-top:#d9c200!important" \
id="x_pfptBanner7gmossp"> <div id="x_pfptBanner7gmossp">
<div id="x_pfptBanner7gmossp">
<p class="MsoNormal" style="line-height:13.5pt;background:#F3E496"><b><span lang="EN" \
style="font-family:"Arial",sans-serif;color:black">This Message Is From an \
External Sender <o:p></o:p></span></b></p>
</div>
</div>
<div>
<p class="MsoNormal" style="background:#F3E496"><span lang="EN" \
style="color:black"> </span><span lang="EN"><o:p></o:p></span></p> </div>
</div>
<div>
<p class="MsoNormal" style="mso-line-height-alt:.75pt"><span \
style="font-size:1.0pt;color:white">ZjQcmQRYFpfptBannerEnd<o:p></o:p></span></p> \
</div> <div>
<p class="xmsonormal"><span style="font-family:"Courier New",serif">Hi \
Ben,</span><o:p></o:p></p> <p class="xmsonormal"><span \
style="font-family:"Courier New",serif"> </span><o:p></o:p></p> <p \
class="xmsonormal"><span lang="EN-US" style="font-family:"Courier \
New",serif">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 :-( </span><o:p></o:p></p>
<p class="xmsonormal"><span lang="EN-US" style="font-family:"Courier \
New",serif"> </span><o:p></o:p></p> <p class="xmsonormal"><span \
lang="EN-US" style="font-family:"Courier New",serif">We can't impose that \
the configuration parameters are always supplied as binary \
blobs.</span><o:p></o:p></p> <p class="xmsonormal"><span lang="EN-US" \
style="font-family:"Courier New",serif"> </span><o:p></o:p></p> <p \
class="xmsonormal"><span lang="EN-US" style="font-family:"Courier \
New",serif">Cheers,</span><o:p></o:p></p> <p class="xmsonormal"><span \
lang="EN-US" style="font-family:"Courier \
New",serif">Med</span><o:p></o:p></p> <p class="xmsonormal"><span lang="EN-US" \
style="font-family:"Courier New",serif"> </span><o:p></o:p></p> <div \
style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"> <div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="xmsonormal"><b>De :</b> Ben Schwartz <<a \
href="mailto:bemasc@meta.com">bemasc@meta.com</a>> <br>
<b>Envoyé :</b> jeudi 5 octobre 2023 15:21<br>
<b>À :</b> BOUCADAIR Mohamed INNOV/NET <<a \
href="mailto:mohamed.boucadair@orange.com">mohamed.boucadair@orange.com</a>>; \
Tommy Pauly <<a href="mailto:tpauly@apple.com">tpauly@apple.com</a>>; Paul \
Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>><br> \
<b>Cc :</b> <a href="mailto:ipsec@ietf.org">ipsec@ietf.org</a>; Valery Smyslov \
<<a href="mailto:svan@elvis.ru">svan@elvis.ru</a>>; <a \
href="mailto:ipsecme-ads@ietf.org">ipsecme-ads@ietf.org</a>; <a \
href="mailto:ipsecme-chairs@ietf.org"> ipsecme-chairs@ietf.org</a>; Dan Wing <<a \
href="mailto:dan@danwing.org">dan@danwing.org</a>>; Tirumaleswar Reddy <<a \
href="mailto:kondtir@gmail.com">kondtir@gmail.com</a>><br> <b>Objet :</b> Re: \
[IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 \
<draft-ietf-ipsecme-add-ike-14> for your review)<o:p></o:p></p> </div>
</div>
<p class="xmsonormal"> <o:p></o:p></p>
<div>
<p class="xmsonormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">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.</span><o:p></o:p></p> </div>
<div>
<p class="xmsonormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="xmsonormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">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.</span><o:p></o:p></p> </div>
<div>
<p class="xmsonormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="xmsonormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">--Ben \
Schwartz</span><o:p></o:p></p> </div>
<div>
<p class="xmsonormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="xmsonormal"><span \
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">[1] <a \
href="https://www.ietf.org/archive/id/draft-ietf-add-dnr-16.html#section-3.1.8" \
id="LPlnk580517">https://www.ietf.org/archive/id/draft-ietf-add-dnr-16.html#section-3.1.8</a></span><o:p></o:p></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="x_divRplyFwdMsg">
<p class="xmsonormal"><b><span style="color:black">From:</span></b><span \
style="color:black"> IPsec <<a \
href="mailto:ipsec-bounces@ietf.org">ipsec-bounces@ietf.org</a>> on behalf of <a \
href="mailto:mohamed.boucadair@orange.com">mohamed.boucadair@orange.com</a> <<a \
href="mailto:mohamed.boucadair@orange.com">mohamed.boucadair@orange.com</a>><br> \
<b>Sent:</b> Thursday, October 5, 2023 2:46 AM<br> <b>To:</b> Tommy Pauly <<a \
href="mailto:tpauly@apple.com">tpauly@apple.com</a>>; Paul Wouters <<a \
href="mailto:paul@nohats.ca">paul@nohats.ca</a>><br> <b>Cc:</b> <a \
href="mailto:ipsec@ietf.org">ipsec@ietf.org</a> <<a \
href="mailto:ipsec@ietf.org">ipsec@ietf.org</a>>; Valery Smyslov <<a \
href="mailto:svan@elvis.ru">svan@elvis.ru</a>>; <a \
href="mailto:ipsecme-ads@ietf.org">ipsecme-ads@ietf.org</a> <<a \
href="mailto:ipsecme-ads@ietf.org">ipsecme-ads@ietf.org</a>>; <a \
href="mailto:ipsecme-chairs@ietf.org">ipsecme-chairs@ietf.org</a> <<a \
href="mailto:ipsecme-chairs@ietf.org">ipsecme-chairs@ietf.org</a>>; Dan Wing \
<<a href="mailto:dan@danwing.org">dan@danwing.org</a>>; Tirumaleswar Reddy \
<<a href="mailto:kondtir@gmail.com">kondtir@gmail.com</a>><br> <b>Subject:</b> \
Re: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 \
<draft-ietf-ipsecme-add-ike-14> for your review)</span> <o:p></o:p></p>
<div>
<p class="xmsonormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="xmsonormal">!-------------------------------------------------------------------|<br>
This Message Is From an External Sender<br>
<br>
> -------------------------------------------------------------------!<br>
<br>
Hi Tommy, all,<br>
<br>
One comment on this part: <br>
<br>
> the binary format for the parameters, and it doesn't require the IKE<br>
> implementation to do any parsing, etc. on that.<br>
<br>
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.<br> <br>
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: <a href="https://boucadair.github.io/dnr-svcb-registry/draft-wb-add-svcb-registry-update.html">
https://boucadair.github.io/dnr-svcb-registry/draft-wb-add-svcb-registry-update.html</a> \
(not published yet).<br> <br>
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. <br>
<br>
Cheers,<br>
Med<br>
<br>
> -----Message d'origine-----<br>
> De : Tommy Pauly <<a \
href="mailto:tpauly@apple.com">tpauly@apple.com</a>><br> > Envoyé : jeudi \
5 octobre 2023 04:44<br> > À : Paul Wouters <<a \
href="mailto:paul@nohats.ca">paul@nohats.ca</a>><br> > Cc : BOUCADAIR \
Mohamed INNOV/NET <<a \
href="mailto:mohamed.boucadair@orange.com">mohamed.boucadair@orange.com</a>>;<br> \
> <a href="mailto:ipsec@ietf.org">ipsec@ietf.org</a>; Valery Smyslov <<a \
href="mailto:svan@elvis.ru">svan@elvis.ru</a>>; <a \
href="mailto:ipsecme-ads@ietf.org">ipsecme-ads@ietf.org</a>;<br> > <a \
href="mailto:ipsecme-chairs@ietf.org">ipsecme-chairs@ietf.org</a>; Dan Wing <<a \
href="mailto:dan@danwing.org">dan@danwing.org</a>>; Tirumaleswar<br> > Reddy \
<<a href="mailto:kondtir@gmail.com">kondtir@gmail.com</a>><br> > \
Objet : Re: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464<br> > \
<draft-ietf-ipsecme-add-ike-14> for your review)<br> > <br>
> As with DNR, I definitely think we should be using the wire format<br>
> here (for communicating on the wire). The IKE option here would carry<br>
> the binary format for the parameters, and it doesn't require the IKE<br>
> implementation to do any parsing, etc on that.<br>
> <br>
> Since it looks like there's good consensus on the DNR side in the ADD<br>
> WG, I think the most important thing to do is ensure the same format<br>
> is used for IKE as is used elsewhere. For DDR, DNR, and this IKE<br>
> extension, they should all use the same format, whether the<br>
> information is in a DNS packet, a DHCP packet, or an IKE packet.<br>
> <br>
> Thanks,<br>
> Tommy<br>
> <br>
> > On Oct 4, 2023, at 5:28 AM, Paul Wouters <<a \
href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br> > ><br>
> > As I said over the other side, I prefer presentation format. Here<br>
> that is even more true than over at the dhcp server because ike<br>
> daemons (server AND client) tend to not implement dns wire format.<br>
> ><br>
> > Presentation format would be to reject this change.<br>
> ><br>
> > But whichever is picked, if I am in the rough, do make it the same<br>
> format for both drafts.<br>
> ><br>
> > Paul<br>
> ><br>
> > Sent using a virtual keyboard on a phone<br>
> ><br>
> >> On Oct 4, 2023, at 06:33, <a \
href="mailto:mohamed.boucadair@orange.com">mohamed.boucadair@orange.com</a> \
wrote:<br> > >><br>
> >> Hi all, =<br>
> >><br>
> >><br>
> >> This document is already in AUTH48-DONE but still not published yet<br>
> >> because= of a normative dependency (see more about the cluster at<br>
> >><br>
> <a href="https://www/">https://eur03.safelinks.protection.outlook.com/?url=https://www</a>
<br>
> >> .rfc-<br>
> %2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C9255f776e6cc<br>
> >><br>
> 4c03710d08dbc54d09a2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638<br>
> >><br>
> 320706888240742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV<br>
> >><br>
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=j1S53uWVH<br>
> >> CJoqPS%2BIWoKaFJRUjaz1zC1k2h1FKLEAoQ%3D&reserved=0=<br>
> >> editor.org/auth48/C461).<br>
> >><br>
> >> A late issue was raised about the encoding of the service<br>
> parameters<br>
> >> (repre= sentation format vs wire format). A summary can be found<br>
> at:<br>
> >> <a href="https://mailar=">https://mailar=</a> <br>
> chive.ietf.org/arch/msg/add/qU_TaosKNhojs3h3ojUb0B_bpXg/.<br>
> >><br>
> >> In order to be consistent with the consensus in ADD, I suggest we<br>
> >> update RF= C-to-be 9464 as follows: =<br>
> >><br>
> >><br>
> >> OLD:<br>
> >> Service Parameters (SvcParams) (variable) - Specifies a set \
of<br> > >> service parameters that are encoded \
following the rules in<br> > >> Section 2.1 of \
[RFC9460]. =<br> > >><br>
> >><br>
> >> NEW:<br>
> >> Service Parameters (SvcParams) (variable) - Specifies a set \
of<br> > >> service parameters that are encoded \
following the same rules<br> > >> for encoding \
SvcParams using the wire format specified<br> > >> \
in Section 2.2 of [RFC9460]. =<br> > >><br>
> >><br>
> >> The text may seem verbose but the intent is to avoid ambiguity and<br>
> be<br>
> >> expli= cit about which part of Section 2.2 of [RFC9460].<br>
> >><br>
> >> Unless we hear an objection by the end of the week, we will request<br>
> >> the RFC= Editor to make this change. =<br>
> >><br>
> >><br>
> >> Cheers,<br>
> >> Med<br>
> >><br>
____________________________________________________________________________________________________________<br>
Ce message et ses pieces jointes peuvent contenir des informations confidentielles \
ou privilegiees et ne doivent donc<br> pas etre diffuses, exploites ou copies sans \
autorisation. Si vous avez recu ce message par erreur, veuillez le signaler<br> a \
l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques \
etant susceptibles d'alteration,<br> Orange decline toute responsabilite si ce \
message a ete altere, deforme ou falsifie. Merci.<br> <br>
This message and its attachments may contain confidential or privileged information \
that may be protected by law;<br> they should not be distributed, used or copied \
without authorisation.<br> If you have received this email in error, please notify \
the sender and delete this message and its attachments.<br> As emails may be altered, \
Orange is not liable for messages that have been modified, changed or falsified.<br> \
Thank you.<br> _______________________________________________<br>
IPsec mailing list<br>
<a href="mailto:IPsec@ietf.org">IPsec@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/ipsec">https://www.ietf.org/mailman/listinfo/ipsec</a>
<o:p></o:p></p>
</div>
</div>
</div>
</div>
<pre>____________________________________________________________________________________________________________<o:p></o:p></pre>
<pre>Ce message et ses pieces jointes peuvent contenir des informations \
confidentielles ou privilegiees et ne doivent donc<o:p></o:p></pre> <pre>pas etre \
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par \
erreur, veuillez le signaler<o:p></o:p></pre> <pre>a l'expediteur et le detruire \
ainsi que les pieces jointes. Les messages electroniques etant susceptibles \
d'alteration,<o:p></o:p></pre> <pre>Orange decline toute responsabilite si ce message \
a ete altere, deforme ou falsifie. Merci.<o:p></o:p></pre> \
<pre><o:p> </o:p></pre> <pre>This message and its attachments may contain \
confidential or privileged information that may be protected by law;<o:p></o:p></pre> \
<pre>they should not be distributed, used or copied without \
authorisation.<o:p></o:p></pre> <pre>If you have received this email in error, please \
notify the sender and delete this message and its attachments.<o:p></o:p></pre> \
<pre>As emails may be altered, Orange is not liable for messages that have been \
modified, changed or falsified.<o:p></o:p></pre> <pre>Thank you.<o:p></o:p></pre>
</div>
</div>
</div>
<pre>_________________<wbr>______________________________<wbr>______________________________<wbr>______________________________<wbr>_
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.</pre></body> </html>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--===============8903891575848657177==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic