Re: [Last-Call] Opsdir telechat review of draft-ietf-acme-dtnnodeid-10

[Brian Sipos <[e-mail]>]

Linda,
To provide some clarification: a "delay-tolerant network" isn't just a
descriptive term, it is a specific type of overlay network operating with
the Bundle Protocol of RFC 9171 in accordance with the principals of RFC
4838. This proposed validation method is both conceptually and procedurally
analogous to the email validation of RFC 8823, and a DTN can be thought of
in the same way as an email transport network: email addresses exist
independently of the IP addresses or DNS names of the clients used to
originate and receive those email messages, just as DTN Node IDs (and the
BP Agents that transfer bundles) exist independently of whatever network,
IP or otherwise, that transports bundles addressed with those Node IDs.
This is why the RFC 8823 validation mechanism exists separately from the
IP/DNS mechanisms, and is why the DTN Node ID mechanism requires its own
mechanism.

Brian S.

On Fri, Oct 21, 2022 at 6:28 PM Linda Dunbar <[e-mail]>
wrote:

> 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 <[e-mail]>
> *Date: *Friday, October 21, 2022 at 2:33 PM
> *To: *Linda Dunbar <[e-mail]>
> *Cc: *Roman Danyliw <[e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *Re: Opsdir telechat review of draft-ietf-acme-dtnnodeid-10
>
>
>
> Linda,
>
>
>
> 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?
>
>
>
> Deb Cooley
>
>
>
> On Fri, Oct 21, 2022 at 2:02 PM Linda Dunbar <[e-mail]>
> wrote:
>
> 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" <[e-mail]> 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 <[e-mail]>
>     > Sent: Friday, October 21, 2022 1:48 PM
>     > To: Roman Danyliw <[e-mail]>; [e-mail]
>     > Cc: [e-mail]; [e-mail];
> [e-mail]
>     > 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" <[e-mail]> 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 <[e-mail]>
>     >     > Sent: Friday, October 21, 2022 12:46 PM
>     >     > To: Roman Danyliw <[e-mail]>; [e-mail]
>     >     > Cc: [e-mail]; [e-mail];
> last-
>     > [e-mail]
>     >     > 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" <
> [e-mail]>
>     >     > 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" <[e-mail]>
> 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=https%3A%2F%2Fmailarc
>     >     > hive.ietf.org
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhive.ietf.org%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C730410093b014e8f43ba08dab39b2684%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638019776213707001%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dG%2BVshKr890CZF2wztj6nT3rL5HGUC19dOp1xxfcWEg%3D&reserved=0>
> %2Farch%2Fmsg%2Flast-
>     >     >
>     > call%2FnujBgHd6ZKHY6fG58ZWBKzFGVWs%2F&amp;data=05%7C01%7Clinda.
>     >     >
>     > dunbar%40futurewei.com
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C730410093b014e8f43ba08dab39b2684%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638019776213707001%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y3CjeJ7h%2FTi%2FEkx7jwTS7dL5H1t4FO8pokNaiqskckU%3D&reserved=0>
> %7C3d47157879904a302e3008dab2f65009%7C0fee
>     >     >
>     > 8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638019068235813966%7CUn
>     >     >
>     > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
>     >     >
>     > 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=t83ICajIF%2FEIKz
>     >     > ibHtGs0T9FFSQpSFmBxKdxxgGHkPY%3D&amp;reserved=0
>     >     >
>     >     >         > -----Original Message-----
>     >     >         > From: Linda Dunbar via Datatracker <[e-mail]
> >
>     >     >         > Sent: Thursday, October 20, 2022 6:55 PM
>     >     >         > To: [e-mail]
>     >     >         > Cc: [e-mail];
> [e-mail]; last-
>     >     > [e-mail]
>     >     >         > 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
>     >     >         >
>     >     >
>     >     >
>     >
>
>