Subject: Re: [dtn] draft-ietf-dtn-bpbis-25: ABNF "dtn" URI scheme

From: Loiseau lucien <[email-masked]>
Date: Tue, 1 Sep 2020 17:09:14 +0800

Hi all,

I am bumping libdtn [1] to upgrade it with latest development (currently
version 26)
 and I have the same question as Alvar. Can we have clarification for the
dtn uri specification?

Also, thinking about the implications of this update for the dtn scheme,
the RFC 3986
states that the double slash should only be used if authority is present.

> URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
>
>       hier-part   = "//" authority path-abempty
>                   / path-absolute
>                   / path-rootless
>                   / path-empty
>
>    [..] When authority is not present, the path cannot begin with two slash
>    characters ("//").

An authority carries a sense of hierarchy as it creates a namespace:

> 3.2.  Authority
>
>    Many URI schemes include a hierarchical element for a naming
>    authority so that governance of the name space defined by the
>    remainder of the URI is delegated to that authority (which may, in
>    turn, delegate it further).

So I wonder about the motivation for this update, because until recently
the dtn eid did not carry any semantic,
but now it does carry a sense of authority,  is the goal to create a
structured hierarchy among dtn operators ?

Also another question maybe for Ed, with the introduction of DTN
authorities, should BPSEC be updated to be
able to carry a certificate that would authenticates a source EID? This
could be done with the *common-name*
field in the X.509 format that encompasses all dtn eid that belongs to a
certain namespace. For instance,
a Common Name: myauthority that apply to all the bundle whose source EID
starts with dtn://myauthority/

pushing it further, we could have a hierarchy *.myauthority covering all
the possible sub-namespace:

dtn://sub1.myauthority/
dtn://sub2.myauthority/

also node-name is specified as at list of at least 1 VCHAR which is the set
of all visible character,
The VCHAR set does include the '/' which is used for the name-delim so that
we won't be able to
separate the node-name from the demux without making assumptions.
Given this, I suggest to change the specification of node-name to prevent
ambiguity with the slash:

node-name = 1* ( ALPHA / DIGIT / "-" / "." / "_"  )

Regards,
Lucien

[1] https://github.com/DisruptedSystems/Terra/
[2] https://www.ietf.org/rfc/rfc3986.txt

On Fri, May 29, 2020 at 8:58 PM Alvar Penning <[email-masked]> wrote:

> Dear all,
>
> thanks for releasing the 25th draft of the Bundle Protocol. As I read
> the changes, I found the Augmented Backus-Naur Form of the URI schemas
> quite useful. However, I have a question about this.
>
> In section 4.1.5.1.1[0] a straight forward ABNF is defined for the
> "dtn" URI scheme:
>
> > dtn-uri = "dtn:" dtn-hier-part
> > dtn-hier-part = "//" node-name name-delim demux ; a path-rootless
> > node-name = 1*VCHAR
> > name-delim = "/"
> > demux = *VCHAR
>
> Some `dtn-uri` is defined as the concatenation[1] of "dtn:" and a
> `dtn-hier-part`. A `dtn-hier-part` starts with two leading slashes
> ("//") and one slash ("/", `name-delim`) follows a nonempty
> `node-name`. Various characters might follow. The line ends with a
> comment[2].
>
> Thus, some "dtn" URI has at least the following form: "dtn://NODE-NAME/"
>
> The following paragraph within this section defines the null endpoint as
> "dtn:none". However, as far as I understand this does not fit the ABNF
> defined above.
>
> If I am not wrong on this, I would like to suggest a new rule for the
> "none" `dtn-hier-part`. This could look like the following:
>
> > dtn-hier-part =  "none"
> > dtn-hier-part =/ "//" node-name name-delim demux
>
> Otherwise, the null endpoint could be renamed to "dtn://none/" to match
> the current ABNF. Note, a node named "none" and the null endpoint may
> get mixed up.
>
> I would be pleased about comments in this regard.
>
> Best regards,
> Alvar
>
>
> [0]:https://tools.ietf.org/html/draft-ietf-dtn-bpbis-25#section-4.1.5.1.1
> [1]:https://tools.ietf.org/html/rfc5234#section-3.1
> [2]:https://tools.ietf.org/html/rfc5234#section-3.9
>
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

-- 
--
Lucien Loiseau

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Tue, 1 Sep 2020 14:22:47 +0000

Weirdly, I don’t remember reading Alvar’s email of May 29 and I don’t have it in my records.  I certainly agree with his suggestion regarding the definition of dtn-hier-part.

The intent of the dtn scheme ABNF in the bpbis specification was simply to document the syntax that has long been common practice, and I have no doubt that this documentation can be improved.  The introduction of a new authority concept was not intended, nor the establishment of a structured hierarchy among DTN operators.  In practice, though, I think the node names used in dtn-scheme EIDs are usually DNS names that conform to these semantics, so perhaps we are already implicitly aligned.  Addressing these semantic points explicitly could be time-consuming and even contentious, so I would prefer that the bpbis specification remain generally silent on them.

But I agree with the suggestion to revise the definition of node-name.

Scott

From: dtn <[email-masked]> On Behalf Of Loiseau lucien
Sent: Tuesday, September 1, 2020 2:09 AM
To: Alvar Penning <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [dtn] draft-ietf-dtn-bpbis-25: ABNF "dtn" URI scheme

Hi all,

I am bumping libdtn [1] to upgrade it with latest development (currently version 26)
 and I have the same question as Alvar. Can we have clarification for the dtn uri specification?

Also, thinking about the implications of this update for the dtn scheme, the RFC 3986
states that the double slash should only be used if authority is present.

>    turn, delegate it further).
So I wonder about the motivation for this update, because until recently the dtn eid did not carry any semantic,
but now it does carry a sense of authority,  is the goal to create a structured hierarchy among dtn operators ?

Also another question maybe for Ed, with the introduction of DTN authorities, should BPSEC be updated to be
able to carry a certificate that would authenticates a source EID? This could be done with the common-name
field in the X.509 format that encompasses all dtn eid that belongs to a certain namespace. For instance,
a Common Name: myauthority that apply to all the bundle whose source EID starts with dtn://myauthority/

pushing it further, we could have a hierarchy *.myauthority covering all the possible sub-namespace:

dtn://sub1.myauthority/
dtn://sub2.myauthority/

also node-name is specified as at list of at least 1 VCHAR which is the set of all visible character,
The VCHAR set does include the '/' which is used for the name-delim so that we won't be able to
separate the node-name from the demux without making assumptions.
Given this, I suggest to change the specification of node-name to prevent ambiguity with the slash:

Regards,
Lucien

[1] https://github.com/DisruptedSystems/Terra/<https://urldefense.us/v3/__https:/github.com/DisruptedSystems/Terra/__;!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAOpRd0RI$>
[2] https://www.ietf.org/rfc/rfc3986.txt<https://urldefense.us/v3/__https:/www.ietf.org/rfc/rfc3986.txt__;!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAmDogEN0$>

On Fri, May 29, 2020 at 8:58 PM Alvar Penning <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Best regards,
Alvar

[0]:https://tools.ietf.org/html/draft-ietf-dtn-bpbis-25#section-4.1.5.1.1<https://urldefense.us/v3/__https:/tools.ietf.org/html/draft-ietf-dtn-bpbis-25*section-4.1.5.1.1__;Iw!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAcIILQZc$>
[1]:https://tools.ietf.org/html/rfc5234#section-3.1<https://urldefense.us/v3/__https:/tools.ietf.org/html/rfc5234*section-3.1__;Iw!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAZdR4jr4$>
[2]:https://tools.ietf.org/html/rfc5234#section-3.9<https://urldefense.us/v3/__https:/tools.ietf.org/html/rfc5234*section-3.9__;Iw!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAgtylS2U$>

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn<https://urldefense.us/v3/__https:/www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAMgrCwKY$>

--
--
Lucien Loiseau

---

From: Brian Sipos <[email-masked]>
Date: Tue, 1 Sep 2020 14:29:33 +0000

Lucien,
Regarding the VCHAR-and-slash logic, the current spec is ambiguous about where a node-name ends and what really are the allowed node-name characters. To allow existing URI parsers and logic, it seems it may be easiest to take the existing URI "reg-name" definition from the Host section [1].

Regarding Source node authentication, this is already achievable using a sequence of existing RFCs and drafts:

  1.  A PKIX certificate can be issued to a Node ID as described in [2] (using a SAN of type URI)
  2.  The certificate can be transported in COSE/BPSec [4] block-integrity block containing an x5chain [5] structure (or one of the other x5 structures) and an RSA/ECDSA signature. The integrity block target could be just the primary block, or multiple blocks.
  3.  The PKIX cert (chain) would then be transported as part of the bundle and the signature would ensure that the security source was the older of the associated private key.

When signing multiple blocks there will be some redundancy here, as each target's result needs to carry the certificate data due to the independent-processing requirement of BIBs [6]. I could revise [4] to include a block-wide parameter which can contain only target-independent key material. This is an interesting use case.

[1] https://tools.ietf.org/html/rfc3986#section-3.2.2
[2] https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-21
[4] https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose-01
[5] https://tools.ietf.org/html/draft-ietf-cose-x509-06
[6] https://tools.ietf.org/html/draft-ietf-dtn-bpsec-22#section-5.1.2

________________________________
From: dtn <[email-masked]> on behalf of Loiseau lucien <[email-masked]>
Sent: Tuesday, September 1, 2020 05:09
To: Alvar Penning <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [dtn] draft-ietf-dtn-bpbis-25: ABNF "dtn" URI scheme

Hi all,

dtn://sub1.myauthority/
dtn://sub2.myauthority/

Regards,
Lucien

[1] https://github.com/DisruptedSystems/Terra/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDisruptedSystems%2FTerra%2F&data=02%7C01%7CBSipos%40rkf-eng.com%7C0f2a9c1798d640a8faa608d84e56c590%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637345481891025946&sdata=oHl9iDDh%2FHj3%2FjT1cjCzhxnyp%2BjgNHxKbFT7YwHX%2B6Q%3D&reserved=0>
[2] https://www.ietf.org/rfc/rfc3986.txt<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfc%2Frfc3986.txt&data=02%7C01%7CBSipos%40rkf-eng.com%7C0f2a9c1798d640a8faa608d84e56c590%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637345481891025946&sdata=C4arE%2Fqubg4a%2B2ROAMFn6l2M6fXwNzdeHAn%2FLa0Wt8I%3D&reserved=0>

Best regards,
Alvar

[0]:https://tools.ietf.org/html/draft-ietf-dtn-bpbis-25#section-4.1.5.1.1<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dtn-bpbis-25%23section-4.1.5.1.1&data=02%7C01%7CBSipos%40rkf-eng.com%7C0f2a9c1798d640a8faa608d84e56c590%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637345481891035933&sdata=E5HOSJUfXr9Apa0op09HX4z9LMIfTNQkyiJ4CC9yF24%3D&reserved=0>
[1]:https://tools.ietf.org/html/rfc5234#section-3.1<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5234%23section-3.1&data=02%7C01%7CBSipos%40rkf-eng.com%7C0f2a9c1798d640a8faa608d84e56c590%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637345481891035933&sdata=iBVDnV%2F3bmCjUs5nws%2FcRKy7QN%2FwtB1inj4d7TfMfzY%3D&reserved=0>
[2]:https://tools.ietf.org/html/rfc5234#section-3.9<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5234%23section-3.9&data=02%7C01%7CBSipos%40rkf-eng.com%7C0f2a9c1798d640a8faa608d84e56c590%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637345481891045934&sdata=CUu8ov6xV3fBv6ubySs3i4nRafhAvX0jBNLhOhCgaPA%3D&reserved=0>

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn&data=02%7C01%7CBSipos%40rkf-eng.com%7C0f2a9c1798d640a8faa608d84e56c590%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637345481891045934&sdata=PmI38QaZ08ISkZpoc5gK7MNj%2FA80efE5uab4cPgKN4M%3D&reserved=0>

--
--
Lucien Loiseau