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

[Linda Dunbar <[e-mail]>]

Brian,

Thank you very much for the detailed explanation.

Linda

From: Brian Sipos <[e-mail]>
Date: Friday, October 21, 2022 at 6:16 PM
To: Linda Dunbar <[e-mail]>
Cc: Deb Cooley <[e-mail]>, 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,
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]<mailto:[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]<mailto:[e-mail]>>
Date: Friday, October 21, 2022 at 2:33 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: Roman Danyliw <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
    > Sent: Friday, October 21, 2022 1:48 PM
    > To: Roman Danyliw <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
    > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
    >     > Sent: Friday, October 21, 2022 12:46 PM
    >     > To: Roman Danyliw <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
    >     > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; last-
    > [e-mail]<mailto:[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]<mailto:[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]<mailto:[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%7C9cf042b92da641a85a7608dab3ba47a8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638019909933889052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Nt50683UmXATnBNqEIoxg6dbHEwengsF7sGs8BpMswI%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%7C9cf042b92da641a85a7608dab3ba47a8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638019909934045240%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=X2FY5HSuhP7BYqtPJ5P4d8o%2BhL7N20bJX46QUHZgIoQ%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]<mailto:[e-mail]>>
    >     >         > Sent: Thursday, October 20, 2022 6:55 PM
    >     >         > To: [e-mail]<mailto:[e-mail]>
    >     >         > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; last-
    >     > [e-mail]<mailto:[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
    >     >         >
    >     >
    >     >
    >