Deb,
The discussion stemmed from my question about the mechanism specified in the draft-ietf-acme-dtnnodeid-10 not touching upon the special properties of Delay Tolerant. For example, are there any special considerations for the satellite network
that requires hours or days of the round trip instead of the traditional network of ms for the round trip?
This triggered me to ask if the mechanism is applicable to validate IDs in other types of networks, like SD-WAN.
Linda
From: Deb Cooley <debcooley1@xxxxxxxxx>
Date: Friday, October 21, 2022 at 2:33 PM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
Cc: Roman Danyliw <rdd@xxxxxxxx>, "ops-dir@xxxxxxxx" <ops-dir@xxxxxxxx>, "acme@xxxxxxxx" <acme@xxxxxxxx>, "draft-ietf-acme-dtnnodeid.all@xxxxxxxx" <draft-ietf-acme-dtnnodeid.all@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx>
Subject: Re: Opsdir telechat review of draft-ietf-acme-dtnnodeid-10
I'm now very confused. The original topic was comments on a DTN acme draft. How did we get to discussing Virtual Network IDs of SD-WAN edge devices?
Do you want to get X.509 certificates for these devices? Or do you have something else in mind to validate these devices?
Roman,
Thanks.
I don't see how DTN wg is relevant, as the SD-WAN is NOT Delay Tolerant Network. More relevance is on the "certificate issuance mechanism" to validate if the IDs advertised by a remote node are legitime.
Does ACME Wg work on "Certificate issuance mechanism" for remote node IDs?
Linda
On 10/21/22, 12:53 PM, "Roman Danyliw" <rdd@xxxxxxxx> wrote:
IMO, the simplest thing would be to pose this question on the DTN WG mailing list. This very specific work is being done in the ACME WG because it has the expertise on the certificate issuance mechanism, but I see you applicability to SD-WAN as more general.
Roman
> -----Original Message-----
> From: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
> Sent: Friday, October 21, 2022 1:48 PM
> To: Roman Danyliw <rdd@xxxxxxxx>;
ops-dir@xxxxxxxx
> Cc: acme@xxxxxxxx;
draft-ietf-acme-dtnnodeid.all@xxxxxxxx;
last-call@xxxxxxxx
> Subject: Re: Opsdir telechat review of draft-ietf-acme-dtnnodeid-10
>
> Roman,
>
> Can you give me a few names with who I can chat to find out more?
>
> Thank you
>
> Linda
>
> On 10/21/22, 12:38 PM, "Roman Danyliw" <rdd@xxxxxxxx> wrote:
>
> Hi Linda!
>
> As I understand the scenario below, it would align to the work in this
> document only to the degree that the SD-WAN network would be an underlay
> to the DTN Bundle Protocol (via some as of yet undefined convergence layer)
> and the Virtual Network IDs would have an easy mapping to the DTN-specific
> addressing mechanism (Endpoint IDs per Section 4.2.5 of RFC9171). I'll let the
> DTN experts correct me or provide more insight on the alignment.
>
> As an aside, there is a critical IANA issue with this document and it is being
> pulled from the planned telechat docket.
>
> Roman
>
> > -----Original Message-----
> > From: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
> > Sent: Friday, October 21, 2022 12:46 PM
> > To: Roman Danyliw <rdd@xxxxxxxx>;
ops-dir@xxxxxxxx
> > Cc: acme@xxxxxxxx;
draft-ietf-acme-dtnnodeid.all@xxxxxxxx; last-
> call@xxxxxxxx
> > Subject: Re: Opsdir telechat review of draft-ietf-acme-dtnnodeid-10
> >
> > Roman,
> >
> > Can the mechanism specified in the draft be used to validate the Virtual
> > Network IDs of SD-WAN edge devices?
> > For example, an SDWAN edge deployed in a remote site, say a shopping
> mall,
> > might advertise the routes and client VPN IDs to the BGP Route-Reflector
> (RR).
> > The RR needs to validate the Client's IDs are legitimate. Can the mechanism
> > specified in the draft do the job?
> >
> > Thanks, Linda
> >
> >
> > On 10/20/22, 10:36 PM, "Linda Dunbar" <linda.dunbar@xxxxxxxxxxxxx>
> > wrote:
> >
> > Roman,
> >
> > With you bringing back the explanation, all makes sense to me now.
> Wish
> > your explanation is incorporated into the document.
> > Thanks, Linda
> >
> > On 10/20/22, 6:53 PM, "Roman Danyliw" <rdd@xxxxxxxx> wrote:
> >
> > Thanks for the re-review Linda.
> >
> > ACME WG: here is the thread from the IETF LC where proposed
> changes
> > were discussed:
> >
>
https://nam11.safelinks.protection.outlook.com/?url="">
> >
hive.ietf.org%2Farch%2Fmsg%2Flast-
> >
> call%2FnujBgHd6ZKHY6fG58ZWBKzFGVWs%2F&data="">
> >
> dunbar%40futurewei.com%7C3d47157879904a302e3008dab2f65009%7C0fee
> >
> 8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638019068235813966%7CUn
> >
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=t83ICajIF%2FEIKz
> > ibHtGs0T9FFSQpSFmBxKdxxgGHkPY%3D&reserved=0
> >
> > > -----Original Message-----
> > > From: Linda Dunbar via Datatracker <noreply@xxxxxxxx>
> > > Sent: Thursday, October 20, 2022 6:55 PM
> > > To: ops-dir@xxxxxxxx
> > > Cc: acme@xxxxxxxx;
draft-ietf-acme-dtnnodeid.all@xxxxxxxx; last-
> > call@xxxxxxxx
> > > Subject: Opsdir telechat review of draft-ietf-acme-dtnnodeid-10
> > >
> > > Reviewer: Linda Dunbar
> > > Review result: Has Issues
> > >
> > > I have reviewed this document as part of the Ops area directorate's
> > ongoing
> > > effort to review all IETF documents being processed by the IESG.
> These
> > > comments were written primarily for the benefit of the Ops area
> > directors.
> > > Document editors and WG chairs should treat these comments just
> like
> > any
> > > other last call comments.
> > >
> > > This document specifies an extension to ACME protocol which allows
> an
> > ACME
> > > server to validate the Delay-Tolerant Networking Node ID for an
> ACME
> > client.
> > >
> > > I had the following comments for the -07 version. I don't think the
> latest
> > > version (-10) resolved my comments.
> > >
> > > Issues:
> > >
> > > The document didn't describe how the Node ID described in this
> > document is
> > > related to the Delay Tolerant Network. I see the mechanism can be
> > equally
> > > used in any network. What are the specifics related to the "Delay
> > Tolerant
> > > Network"?
> > > It would be helpful if the document adds a paragraph explaining the
> > specific
> > > characteristics of the Delay-Tolerant Network that require the
> additional
> > > parameters/types used for validating the Node-ID for an ACME
> client.
> > >
> > > Thank you,
> > >
> > > Linda Dunbar
> > >
> >
> >
>
|
