[Last-Call] Re: Intdir telechat review of draft-ietf-dtn-ipn-update-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jean-Michel,

Thanks for the review, comments inline...

Cheers,
Rick

On Tue, 18 Jun 2024 at 16:34, Jean-Michel Combes via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Jean-Michel Combes
Review result: On the Right Track

Hi,

I am an assigned INT directorate reviewer for draft-ietf-dtn-ipn-update-11.txt.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as NO
OBJECTION.

The following are other issues I found with this document that SHOULD be
corrected/clarified before publication:

3.2.  Allocator Identifiers

<snip>

   If a system does not require interoperable deployment of ipn scheme
   URIs, then the Private Use Node Number range, reserved by the Default
   Allocator (Section 3.2.2) for this purpose SHOULD be used.

<JMC>
IMHO, it should be clearer (1) to have a reference to Section 3.4.3 instead to
Section 3.2.2 and (2) to add the following information in text: - Allocator
Identifier SHOULD be set to zero (0) - Node Number SHOULD be in the “Private
Use” range (cf. Section 9.2) </JMC>

<snip>

You make a valid point, but we have decided to replace the "SHOULD be used" with "are to be used" (not canonical).  I'm not keen to start talking about Id 0 at this point, as we have yet to introduce numeric values (representation detail) and are just talking about generalities, but I have added a cross reference to 3.4.3
 

3.2.1.  Allocator Identifier Ranges

<snip>

With these assignments, any Allocator Identifier whose most-
   significant 25 bits match 0xEE000 belong to organization A.
   Similarly, any Allocator Identifier whose most-significant 28 bits
   match 0xEE080 belong to organization B, and any Allocator Identifier
   whose most-significant 31 bits are 0xEE090 belong to organization C.
   Organisation D has a single Allocator Identifier, and hence a range
   of bit-length 0.

<JMC>
Sorry, but I don’t understand how you get 25 bits for organization A, 28 bits
for organization B and 31 bits for organization B. Is it possible to provide a
formula, please? By the way, are you assuming that Allocator Identifier is
based on 32 bits? </JMC>

<snip>

We were really hoping that this read as 'subnet masking' written in longhand.  And yes, Allocator Ids are all 32-bit unsigned ints. But having re-read, we don't specify that by this point, will update.  
 

3.4.  Special Node Numbers

   Some special-case Node Numbers are defined by the Default Allocator,
   see 'ipn' Scheme URI Default Allocator Node Numbers registry
   (Section 9.2).

<JMC>
It seems that you assume that there will no need of special-case node numbers,
except for the Default Allocator, in the future: is it correct? If so, is it
not dangerous (i.e., complexity to come back from such a decision)? </JMC>

<snip>

5.5.  Private Use ipn EIDs

   Bundles destined for EIDs that use an ipn URI with a Fully-qualified
   Node Number (Section 3.3.1) that is within the "Private Use" range of
   the Default Allocator (Section 3.2.2) are not universally unique, and
   therefore are only valid within the scope of the current
   administrative domain.  This means that any bundle using a Private
   Use ipn EID as a bundle source or bundle destination MUST NOT be
   allowed to cross administrative domains.  All implementations that
   could be deployed as a gateway between administrative domains MUST be
   sufficiently configurable to ensure that this is enforced, and
   operators MUST ensure correct configuration.

<JMC>
IMHO, “MUST” use may be too strong: it is possible that 2 administrative
domains (e.g., two affiliates in a same company) agree to use ipn URI in the
“Private Use” range and to choose different subsets of this last one to ensure
uniqueness. </JMC>

<snip>

We went back and forth on this, but for the purposes of this text, we define "administrative domain" to include "two cooperating admin domains with an out-of-band mechanism to sub-allocate the private use range to avoid clashes", so I think we have your point covered without explicitly describing it.
 

8.2.  Malicious construction

   Malicious construction of a conformant ipn URI is limited to the
   malicious selection of Allocator Identifiers, Node Numbers, and
   Service Numbers.  That is, a maliciously constructed ipn EID could be
   used to direct a bundle to an endpoint that might be damaged by the
   arrival of that bundle or, alternatively, to declare a false source
   for a bundle and thereby cause incorrect processing at a node that
   receives the bundle.  In both cases (and indeed in all bundle
   processing), the node that receives a bundle should verify its
   authenticity and validity before operating on it in any way.

<JMC>
There is no reference to any security mechanism to prevent such a threat: no
security mechanism – equivalent to IP anti-spoofing, exists regarding this
threat? </JMC>

Yes there is: RFC9172 (BPSec) describes an integrity/confidentiality mechanism which can enforce identity at the bundle layer, and RFC9174 defines a convergence (link) layer protocol that includes TLS with support for Node IDs as part of peer certificate exchange.  I'll add a reference.

Thanks in advance for your reply.

Best regards,

JMC.



-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux