Distributed Prefix Assignment Algorithm
draft-ietf-homenet-prefix-assignment-08

I agree with Alvaro and Brian on the need to clarify topology changes.  In Sec 3, I see
"   The algorithm supports dynamically changing topologies:

   o  Nodes may join or leave the set of participating Nodes.

   o  Nodes may join or leave Links.

   o  Links may be joined or split."

and what isn't clearly stated is that when a link fails (partially or fully) or comes into existence ,
is that a topology change?

For instance, if a link fails, surely that shouldn't be a topology change for the prefix assignment,
but rather a matter for routing to handle.  I do see in Sec 4.3 "When a Link is removed, all Assigned Prefixes
assigned to that Link MUST be destroyed."  Perhaps a link removal isn't considered a topology change in this
context because it doesn't cause renumbering??

How is a new Link added to be considered?  How does a router know that its end of a link is the
same link as on another router?  How is a link "removed" versus merely down?

An assumption seems to be that the flooding mechanism can work without any prefix numbering.  That's fine but
would be good to state.  I'm a bit twitchy about the bootstrapping.

I don’t object to the publication of this document, but I do have several comments that I think should help in making it clearer.

Comments:

(1) Topology Changes.  The Introduction reads: "Assigned prefixes do not change in the absence of topology or configuration changes. . .the algorithm also ensures that all assigned prefixes. . .remain unchanged, unless. . .the topology changes and renumbering cannot be avoided.”  But later in Section 3. (Applicability Statement) you wrote that the "algorithm supports dynamically changing topologies”.  

What are then topology changes that may result in renumbering being unavoidable?


(2) To Destroy.  The term “destroy” is used in several places, but it is not defined in Section 2.  It looks like Section 4.2. (Overriding and Destroying Existing Assignments) might define it, but instead it uses “destroy” to to define “Removing an Assigned Prefix”.  Destroy seems to be the local action that may result in removing a Published Assigned Prefix.  Please add to the terminology.


(3) Unique Node IDs.  Having unique Node IDs is important to break ties in the algorithm.  However, the text seems to allow the existence of duplicate IDs for some (undefined) period of time.  Section 3. (Applicability Statement) reads: "Node IDs MAY change over time and be the same on multiple Nodes at some point, but each Node MUST eventually have a Node ID which is unique among the set of participating Nodes.”   How long is “eventually”?   The sentence is (at best) confusing, but it reads as contradicting to me: If multiple Nodes can have the same ID, how can the MUST be enforced?   You mention in the Security Considerations section that an “attacker. . .using a Node ID used by another Node may prevent the correctness and convergence of the algorithm. . .”  Allowing for multiple Nodes to have the same ID is then an attack for however long “eventually” is.

The same type of language (“eventually” and “at some point”) is used on other places.  It would be nice to tighten the text up (where appropriate); for example, the part about “Each Node MUST have a set of non-overlapping Delegated Prefixes..” seems to be ok as it doesn’t mention that at some point the Delegated Prefixes may overlap, just that the sets may not be the same.


(4) How is a Node ID defined?  What I mean is: is it a number, a string, whatever?  It sounds like the specific definition may be left to the Flooding Mechanism, is that true?  If so, then I think it would be a good idea to call it out — this also means that as an operator I may have to redefine my Node ID assignment mechanism if I decide to change the Flooding Mechanism.  The ordering of the Node IDs will also depend on how they are defined.

BTW, “Node ID assignment mechanism” is mentioned in the Security Considerations, but not defined anywhere.  It may of course not be an in-the-network mechanism and simply a manual assignment of IDs — it would be nice to say something about what it is (or may be).


Nits:

(A) Consistency in naming.  

For example: “Available prefix” is defined, but later “available prefix” is used (I think) to refer to the same thing.  Given that common words are used (Available, Valid, etc.) it is important to differentiate when the specific term is used vs just the generic use of the word.

Precedence is defined in Section 2.1, but later not used in Section 4.  That is ok (except for the text in Section 4 that calls it out) given that it looks like the term is used when defining Best Assignment and Valid — I say it "looks like it" because “precedence” (not “Precedence”) is used.  Should it be “Precedence”?

Valid (capital V) is also defined but not used later.  There are a couple of places where maybe “Valid” should replace “valid”.


(B) Section 2. (Terminology)  In the definition of “Private Link”, I think the “MAY” should really be “may”.  There’s nothing normative about the example.


(C) s/received from the Flooding Mechanism/received through the Flooding Mechanism

Well written and clear; thanks.

See Tim's OPS-DIR, as flagged by Joel already.

Tim Chown did the opsdir review. I think some of the criticism is well take and it looks like discussion is ongoing to address it. 

I think brians discuss and the outstanding comments are sufficient to address it.

Tim's review follows


Hi,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These  comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. 

Overall, I believe the draft is ready with minor issues, mainly around presentation and clarity.

As one part of the proposed HNCP protocol, having this distributed prefix distribution algorithm documented is a Good Thing.

Homenet has considered previous work in this area, e.g.both draft-arkko-homenet-prefix-assignment-04 and draft-baker-homenet-prefix-assignment-01 have been discussed in homenet. While those don’t need to be cited, it’s worth noting that homenet has been seeking a self-configuring prefix distribution mechanism for some time (3-4 years).

General comments:

The draft very much throws the reader in at the deep end. It would be very useful if a high-level description of the philosophy of the algorithm were included in the introduction, such that those principles are in the reader’s mind when they read through the remainder of the document, including the description of the algorithm.

Related, there is very little content in the draft. It does not cite or mention that it is used by HNCP, nor does it cite RFC 7368. There is no text describing (even just briefly) why this approach is favoured, or any rationale why this approach is most favoured for HNCP (or regarding the claimed convergence). If those are documented elsewhere, a link/reference would be useful for the reader.

Regarding RFC 7368, the draft could claim compliance with that RFC, in particular Section 3.4.3, given the support for assigned prefix stability described within the draft. Given it is a homenet draft, this would seem appropriate.

Because the draft describes an algorithm, rather than a detailed protocol, many parts of the document omit specifics, e.g. the format of a Node ID, or of the flooded messages. If the document aims to provide the means for a developer to build an implementation of HNCP, this could be problematic. Are these formats going to be described elsewhere, or are they already described somewhere?

What happens if there are not enough prefixes to assign a prefix to each Link? Is there still convergence? What is the failure mode here? RFC 7368 considers this an ‘error’ mode that needs to be indicated to the user. Or would you state an assumption of enough prefixes? Some brief explicit discussion of this, early in the text, would be useful. At present it’s hinted at at the end of Section 4.2 and end of Section 6.

The Terminology section could precede the Introduction for clarity.

Specific comments:

Page 1:
What does “or for other private purposes?” mean in the abstract?

Perhaps the abstract can mention that the algorithm can support prefix stability over reboot given the presence of stable storage.

What does ‘eventually converges’ mean?

Page 2:
Line 3 of introduction, ‘prefix’ rather than ‘prefixes’.

As a homenet draft, should ‘professionally managed networks’ be mentioned here?  Maybe say “as well as other deployment scenarios”?

Page 3:
How is the flooding mechanism made reliable? Or is that down to the method of implementation?

Page 6:
Is this really an applicability statement? I think of something more general here, by default, which this isn’t.

Terms such as 'non-overlapping’ and ‘disjoint’ are used - perhaps be consistent.

Page 7:
At the top, perhaps also mention here that in the moment context ULA prefixes might also be configured by this method, alongside globally unique prefixes.

As an aside - where a moment has two routers advertising a /48 ULA, can this algorithm be used to pick only one to use, or would it by default create prefix assignments on each Link for each 48?

Page 8:
The term ‘considered’ is introduced a little abruptly here in the first bullet point of 4.1.

Page 9:
It may be better for ADOPT_MAX_DELAY and BACKOFF_MAX_DELAY to be explained earlier, rather than forward referenced to Section 7.

Page 10:
‘is not valid’ - maybe that should be ‘is not Valid’, matching the upper case used in the terminology section?

Page 12:
So if the upstream ISP goes away, what happens? Do all Links become unnumbered for global prefixes, continuing to use ULAs if configured? Some clarity here would be nice.

Page 13:
For Randomness, is there a privacy aspect here, that a homenet or a network using this algorithm may choose to randomise prefixes internally over time for privacy reasons (ignoring the complexity that may be introduced elsewhere as a result)? We have considered IID and link layer address randomisation elsewhere recently; this could be argued as another tool in that toolbox. Though adding such text with subsequent comments may lead to delays in publication :)

Page 16:
I don’t think the Node ID assignment mechanism has been described anywhere?

The security considerations do not hint at any solution for the noted threats. There are of course comparative threats to similar algorithms.

Tim



_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

I'd also like to see the security and privacy text Stephen suggests in his first 2 comments.

Thanks.

I support Brian's second Discuss point (on the text raised by Brian Carpenter).

I believe I'm seeing changes to address that. Thank you in advance.

- section 3: I expected some security text here, not to say that
this all needs to be encrypted but rather to say that because
this is flooding, you can't really encrypt it and that hence
this scheme is only suited for smaller deployments and/or those
with lower layer security already in place. (And hence also
probably small.) 

- section 3: Similarly, you could also add some privacy text to
the effect that this scheme only applies where the privacy
characteristics of the various prefixes involved are all
roughtly similar, that is, where there's no real privacy
difference in which prefixes end up with which nodes. (Mind you,
I need to ponder that a bit myself to see if it's really the
case;-)

- sections 4 & 5: I found this impossible to understand in a
(quick) linear reading. I'd find actual code easier tbh. It's
interesting that Barry found this clear though (I did not,
clearly:-) so this isn't a discuss. But why didn't you first
provide an overview of the algorithm? 

- Where is the evidence that the algorithm converges? I'd have
thought there would be a reference to an academic publication
that also described the algorithm and a proof for convergence.