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> 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> 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> 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> 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
