[Apologies for the after-WGLC review]
Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.
Document: draft-ietf-homenet-hncp-07.txt
Reviewer: Thomas Heide Clausen
Review Date: July 21, 2015
IETF LC End Date: <review just after WGLC>
Intended Status: Standards Track
Summary:
o I have significant concerns about this document and recommend
that the Routing ADs discuss these issues further with the
authors.
Comments:
o This document is a profile for and specialization of
draft-ietf-homenet-dncp, and
has a normative dependency on that document. Note that I
produced a
RTG-DIR review of draft-ietf-homenet-dncp with several
suggestions a
short while ago, to which the authors recently responded with
an updated
document. I have not had a chance to review that update, and
iterate
with the authors, yet. I also note a RTG-DIR review by Les
Ginsberg,
as well as several points raised by Juliusz Chroboczek on the
topic of
draft-ietf-homenet-dncp, the resolution of which I believe may
impact
draft-ietf-homenet-hncp somewhat significantly.
This is one reason for my summary (above) of "Significant
concerns..."
-- before this document can be processed,
draft-ietf-homenet-dncp should
be squared off. It is not, however, the only reason
o As a general comment, the document would do well with a good
editorial
overhaul to bring consistency in language usage, consistency in
2119
terminology, coherence in defined terms and their definition,
document
structure, etc.
o Related to this, I found that the lack of a terminology section
was
unfortunate, and ended up -- for helping my own reading of the
document
-- making a napkin-terminology to refer to as I walked through
the doc.
(FWIW, I personally prefer the 2119-paragraph to be part of a
terminology section, although that is a minor issue / personal
preference). The words I'd suggest including, and defining,
would be:
o Node -- is that a router, a host, or both?
Again, I was
given to understand that HOMENET did
not want to redefine
host behavior, and so I believe that
the right term would
be router?
o Privat Link - Common Link -- If you *insist* on
having these
concepts, then they definitely need a
clear-cut definition
here ; I would prefer, though, to not
have those concepts.
o External Interface
o Internal Interface
o Border
o Border router
You "import" a lot of terminology from DNCP and from
[I-D.ietf-homenet-prefix-assignment], and I found myself
constantly
hunting through to figure out which terminology was from where.
Suggest
adding a paragraph to the terminology section (assuming you
make one)
which recapitulates something like:
"Additionally, this document uses terminology from
DNCP,
specificially the terms XXX, YYY, ZZZ are to be
interpreted as
described therein.
This document also uses terminology from
[I-D.ietf-homenet-prefix-assignment], specifically the
terms WWW,
UUU, QQQ are to be interpreted as described therein".
Reason being: when I came across a term (say "Shared Link"), I
wanted
to make sure that I understood what that was. So I went to the
terminology section. Well, there was none. So I went to grep
through
this document. Didn't really find a definition. So I started
looking
through the references to see if there might be something that
made
sense. Fortunately, my guess of what I-D to check first was
right, but
it still was more work than it should have been.
Major Issues:
o I made this very same comment to draft-ietf-homenet-dncp, as I
am going
to make here.
The introduction does not read well; it contains parts of
something that
could be considered as part of an applicability statement
(without it
being called out as such, and without forming a complete
applicability
statement), and does not actually introduce the protocol.
Reading just
the introduction and the abstract, it is very obscure what HNCP
is
actually accomplishing, and why one would chose to use HNCP.
It does, however, transpire that "whatever it is", it imposes a
src-dst
routing protocol -- although, that is actually at odds with the
claim
(from the Abstract) that the use of HNCP allows "...seamless
use of a
routing protocol." ... given that, afaik, no standardized
src-dst
routing protocols currently exist.
As I recommended for DNCP (hey, at least I'm being somewhat
consistent...) I suggest that a proper introduction consisting
of three
parts would be beneficial: (i) what this document is, (ii) what
doing
HNCP actually gets you, and (iii) the operating conditions
under which
HNCP is applicable.
I am calling this out as a major issue, since I believe that it
is
not just editorial, but is a matter of scoping this document
correctly,
and in particular not falling into the trap of "claiming
applicability
where it's not".
o 4. Common Links
From the document:
"HNCP uses the concept of Common Links for some of its
applications.
A Common Link usually refers to a link layer broadcast
domain with
certain properties and is used, e.g., to determine where
prefixes
should be assigned or which neighboring nodes participate
in the
election of a DHCP(v6) server. The Common Link is computed
separately for each local interface, and it always contains
the
local interface. Additionally, if the local interface is
not in
ad-hoc mode, it also contains the set of interfaces that are
bidirectionally reachable from the given local interface,
i.e. every
remote interface of a remote node meeting all of the
following
requirements:"
Several issues here:
0) "refers to a link layer broadcast domain" --
sounds like a
"full broadcast link" or "something that looks
like an Ethernet"
1) "some of its applications" -- what are those?
2) "usually refers to a ..." -- so, that means
that there are
situations where you use it to refer to
something else, then?
Please don't do that....
3) "is computed seperately for each local
interface" -- wait, in
0) it was defined in terms of physical
properties, now it is
something which is computed?
4) "which neighboring nodes participate in the
election of a
DHCP(v6) server" -- is that a hidden
requirement that slid in,
that DHCP(v6) servers are part of the
architecture? SLAAC is
out, then? Is that a conscious architectural
decision?
Now, I actually read in section 5, bullet
number 2 that "if
an interface can receive a delegated prefix by
running a
DHCPv6 client on the interface, it must be
considered
external". So, at least, if a "common link"
connects "internal
interfaces" then if DHCPv6 servers are active
on a common
link, then this imposes constraints on what
these DHCPv6
servers are allowed to serve ... This *really*
merits being
called out, the relationship DNCP-DHCP is
murky, at best.
5) "if the local interface is not in ad-hoc mode"
-- haaaaang on,
if we are talking about an 802.11/WiFi
interface, "ad hoc mode”
does not result in links that look like in 0)
....not at all, actually.
6) "if the local interface is not in ad-hoc mode"
-- I am not sure
that this is actually "the right term" nor that
it is
universally understood. At least, I have
personally had a heck
of a time conveying what that meant when
charaterizing a link —
especually within the IETF"
7) Reading forward in the document, there's
something more on that
in section 5 on page 6 where the document talks
about an "ad hoc
category", and where it actually says something
about
"transitivity properties" -- specifically that
it is not
assumed, then a reference to section 4 is given
as-if there was
any further discussion on this point.
8) "set of interfaces that are bidirectionally
reachable from the
given local interface" -- I take it that this
means that the below
specifies a part of a protocol (HELLO
protocol), which only run
over "ad hoc interface types"?
If "yes" to 8), then I would recommend that you define the
interface
types, and their behaviors, completely -- both what
characteristics you
expect from the interface (and "ad hoc mode" is not
sufficient...), and
what behaviors you exhibit across them. You have, in this text,
half-way
defined "broadcast link type" and half-way defined a
"non-transitive
non-reflexive link type"
Also, I really do not understand the choice of "Common Link" as
section
header, and as a term. How is that definition different from
"an IP
link"? Are the protocol mechanisms that you provide for what
you call
"ad hoc mode" providing something which looks like an IP limk
to "the
rest of the protocol", etc.
I am afraid that I do not understand what a common link is. Are
you
trying to define a link model?
o 3. DNCP Profile
The document reads:
"A node implementing HNCP
SHOULD generate and use a random node identifier. If using a
random node identifier and there is a node identifier
collision,
the node MUST immediately generate and use a new random node
identifier which is not used by any other node."
Awesome, but that raises two questions:
1) How does a node detect identifier collision?
2) How does a node generate an identifier which is
not used by any
other node?
It would seem that if 2) is actually possible, then a colission
should
never ever happen.
Also, if 1) and 2) are done "by this protocol", put in a forward
reference to where the corresponding mechanisms exist. Or if
done by
DNCP or something else, stick in a reference.
As it is, it reads a little like:
"...and then some magic happens, and then poppies and
pink unicorns"
;)
The document reads:
"o HNCP nodes use the following Trickle parameters:
- k SHOULD be 1, as the timer reset when data is
updated and
further retransmissions should handle packet loss."
I am wondering what the justification for "k=1" is here?
Actually, I can
infer what it is: the topology in a homenet is constituted by
full-broadcast Ethernet links, with the assumption that "if one
station
receives a transmission, all stations on the link received the
transmission" -- if so, then this is actually part of the
applicability
statement for HNCP: "MUST only be used on Ethernet-like links
and MUST
NOT be used on non-transitive, non-reflexive, or on lossy,
links".
If this interpretation is correct, then you probably should
explain
yourself -- for once, I am mostly in agreement with the use of
a
SHOULD.
One question, however: for a router with multiple interface, do
you run
the Trickle algorithm per interface? Would probably merit
clarification.
If it is already said in DNCP (I do not recall if it is, and
couldn't
immediately find it), perhaps a reminder and a pointer would be
good?
o Section 4 & 5
The document seems to define a set of interface types and link
types,
but without any clear relationship between them -- and, worse,
without
any discussion of what characterize each, what behaviors are
exhibited
over each, and what impacts on the system/network behavior and
performance each has. Further, the definitions of the different
interface/link types are incomplete, and seem tied to (without
naming
explicitly) specific L2's...hinted at, but not actually
referenced.
o Section 5
The document reads:
"HNCP router's interfaces are either internal, external or
of a
different category derived from the internal one."
So, this text tells me that there are n different categories of
interface, where n>=2 -- but does not tell me what defines those
different interface categories, or what the actual value for n
is. Nor
does this tell me if I should expect different behaviors across
these
interfaces, or not.
Could the document be more specific?
The text goes on:
"It is suitable for both IPv4 and IPv6 (single or
dual-stack) and
determines whether an HNCP interface is internal,
external, or
uses another fixed category."
So what's "another fixed category"? Is that different from "a
different
category derived from the internal one" discussed earlier?
Again, what
behaviors to expect, exhibit, across these?
With that being said, I would really recommend that the
document defines
what a border is, in this context. How do I identify it, what
characterizes a boarder (which perhaps falls off from "what
characterizes an internal and external interface).
I assume that "internal interface" means "internal to the
Internet"
whereas "external" means "external to the internet, i.e., part
of the
homenet" -- right? Of course, I am yanking your chain here, but
you must
define precisely what these mean. External and Internal are
relative
terms...
On that, reading through the algorithm that you give,
eseentially you
define as "external" anything on which a DHCPv4 or DHCPv6-PD
server
answers, correct? Other than having a hard time reconciling
that with
issue 4 under "common links" in Major Issues, that does seem to
assume
an architectural choice which imposes constraints ("thou shalt
not run
a DHCP server inside a homenet whilst running HNCP") which, at
least,
needs to be called out in the applicability statement for HNCP,
and
probably even merits more global discussion and decision by the
WG?
But wait, then below the algorithm I read this:
"In order to avoid conflicts between border discovery
and HNCP
routers running DHCPv4...."
...and then, requirements that such routers must include a
User-Class
string. That actually means that the specified algorithm is
incorrect
-- underspecified: the algorithm must capture the "...unless an
User-Class string of .... is included", where appropriate.
Sure, with efforts of the "...I thought this over, and I am
sure that
the authors must have meant XXXX", it's probably possible to
implement
but I'd much prefer to have the document tell me what to
implement,
rather than have it tell me to guess.
The last paragraph in section 5 is hugely important: that is
where the
normative behavior for each interface category is detailed -
but, I
think, only part of the normative behavior is actually specified
therein. This is relative to what I mentioned earlier, that for
an
interface/link type/category, it would be helpful to have
specified
precisely (i) how to determine if a given interface/link falls
within
it, (ii) what precise behaviors to expect over than
interface/link.
o Section 6
Related to my last comment above to section 5, section 6 brings
out
"border routers" -- which is not actually defined in the
document.
Some specific behavior is specified for a "border router" and
that
brings me to expecting to see:
o A precise definition of when a router is, or is
not, a
border router (given a router, how do I
determine if I
should configure it to exhibit that "specific
behavior"
o A precise and complete definition of which
behaviors a
"border router", once identified, should expect
and exhibit.
The current text does not do that. Again, I could perhaps try
to guess,
but for a document aiming for std.track, I really should not
have to.
o Section 6.1
"Each HNCP router MAY obtain external connection
information from
one or more sources, e.g., DHCPv6-PD [RFC3633],
NETCONF [RFC6241]
or static configuration. This section specifies how
such
information is encoded and advertised."
What is "connection information"? Do you mean "prefixes,
addresses,
routing information, DNS resolvers" and such? Or does it mean
"bitrate,
error rate, propagation delay"? Or something else? Again, I
could
probably guess, and might even get it right, but in a std.track
document
I really shouldn't have to.
"o MAY contain at most one DHCPv6 Data TLV and at most
one DHCPv4
Data TLV encoding options associated with the External
Connection but MUST NOT contain more than one of each
otherwise
the External Connection TLV MUST be ignored.
o MAY contain other TLVs for future use. Such additional
TLVs
MUST be ignored."
Several comments to that specifically, and to the TLV
description in
general (please apply also to the other signals/TLVs as
appropriate, the comments to this TLV description / bullet
apply through
section 6):
0) You define a TLV "EXTERNAL-CONNECTION", within
which you have
other TLVs, correct? Would it not be clearer if
those "other
TLVs" be called "sub-TLVs" and that term used
systematically,
so as to distinguish them from the top-level
DNCP TLVs.
I note that you then set up "sub-sub TLVs" such
as "Prefix
Domain". So that means that we'll see:
o An EXTERNAL-CONNECTION TLV,
containing
o A DELEGATED-PREFIX TLV,
containing
o A PREFIX-DOMAIN
TLV
Correct?
The first question that springs to mind is one
of IANA
registries. Are you setting up, for each TLV
type, a new
registry for sub-TLV-types? Or, are all TLV
types out of one
global space?
More importantly, if out of a global TLV type
space, what
happens if, say, a "PREFIX-DOMAIN" TLV is
received outside of
a "DELEGATED-PREFIX" TLV? Is that valid? Should
it be? What
behavior should I, as an implementer, exhibit
if I receive
that?
This, really, is a question about what the
context for
processing each (sub)TLV os, or should be,
which is not
specified in the document. It is also related
to issue 2) below.
1) I would suggest a phrasing such as:
"MAY contain at most one ... and at most one
DHCPv4 ... with
the external connection."
2) The second part of the first bullet:
"MUST not contain more than one ...
MUST be ignored"
That should, IMO, be a generic comment for all
(sub)-TLVs, and
brought forward to section 6.0 or 6.1, for
example some
wordsmithing on:
"Any received TLV, which does not
satisfy the requirements
specified in the below, MUST be
silently discarded, and
MUST be ignored for processing.
More to the point, these TLVs (and (sub-)TLVs)
are speicified as
being in a specific order, or at least in a
specific hierarchy
(TLV within another TLV) on transmission. What
are the
constraints on their processing? At what point
shall I discard
information based on it being received "out of
place" (such as
a "DELEGATED-PREFIX" TLV not contained in an
"EXTERNAL-CONNECTIVITY" TLV)?
3) This leads to a general question: are all the
constraints on
the sub-TLVs contained in this TLV completely
specified?
I would actually like to see a check-list of
"constraints" that
I could implement checks for, both when
generating and
processing protocol messages.
4) Generally, to the fields in the TLVs, I do not
see the encoding,
(unsigned/signed, endianness, ...) stipulated.
Rather important
for interoperability, this MUST be clarified.
5) I am generally not a great fan of having some
constraints in the
picture (such as the length >= 9) and some in
the text (such as
"MUST NOT have more than n occurences of
FOOBAR").
6) "May contain other TLVs or future use" -- sure,
but then you go
on to say "these MUST be ignored". Strictly
speaking, that means
that you can't "future use" them either. How
about:
"May contain TLVs of other type, for
future use. For the
purporse of the processing specified
in this document,
such TLVs of unknown TLV type MUST be
ignored".
Note the subtlty here: "unknown TLV types" --
what does that
mean? We're actually back at the
IANA/hierarchical/sub-TLV
discussion. Assuming that you have just one,
flat IANA registry,
such as you actually have. An
EXTERNAL-CONNECTIVITY TLV sure is
a "known TLV Type". If you get a
DELEGATED-PREFIX TLV containing
an EXTERNAL-CONNECTIVITY TLV, is that valid, or
must that be
ignored?
So, with the current set-up of IANA registries,
the "unknown TLV
types" is not the right phrase.
My preference in this sort of situation is
actually to set up
hierarchical IANA registries:
o DNCP sets up the top-level TLV
type registry.
o HNCP specifies (from within
that regitry) the
EXTERNAL-CONNECTIVITY TLV type,
which:
o Sets up a new
registry for sub-TLV types
o Allocates the
DELEGATED-PREFIX from that new
registry
(and so on).
What it does is to set up a context in which
"unknown TLV type"
(and such) means something -- and also solves
the rest of the
processing context comments above
Alternatively, sure, you could put something
like:
"May contain TLVs of other type, for
future use. For the
purporse of the processing specified
in this document,
TLVs of types other than FOO, BAR,
FOOBAR, and GNYF type
MUST be ignored".
IMO this is less flexible and leads to more
repetition.
o Section 6.1.2
The document reads:
"Valid Lifetime: The time in seconds the delegated
prefix is
valid. The value is relative to the point in time the
Node-Data TLV
was last published. It MUST be updated whenever the
node
republishes its Node-Data TLV."
I just can't parse that. Well, I can, but what I get doesn't make
sense to me:
"relative to the point in time the Node-Data TLV was last
published"
So, I publish a NODE-DATA TLV. Must I now remember when I did
that, say,
at t0, and then next time I publish a NODE-DATA TLV include (t-t0)
as Valid
Lifetime? That does look like what the text says, but it also
doesn't sound like a "Vaid Lifetime". Given the name of the field,
Lifetime, I would expect it to mean "Upon receiving this TLV, please
consider the information valid for this much time" -- but, that's
not what the text says.
Same comment applies to Preferred Lifetime
Also, from this section:
"* Zero or more Prefix Domain TLVs. In absence of any
such TLV
the prefix is assumed to be generated by an HNCP-router
and for
internal use only."
Could gain from being a little more specific: what is "internal
use
only" (internal to whom?) -- related to my previous comment
about
definition of External/Internal. Also "use" -- do you mean that
"this
prefix MUST NOT be leaked externally, i.e., addresses from
within this
prefix MUST NOT be used as a source address for traffic outside
the
homenet? If so, does this mean that you allow a homenet router
to grab
any odd global prefix and treat as private? Or, is this a
matter of
simply reflecting the already existing "don't route 192.168/16"
(and
equiv.) rules?
Either way, that needs to be clarified.
o 6.2.1
"All HNCP nodes running the prefix assignment algorithm
MUST use the
following parameters:"
First, I think that an element of clarification would be good.
These
parameters, where are they from? Do they come from
[I-D.ietf-homenet-prefix-assignment], are they in that
specification
given as "optional" (so that one might get the idea to not use
them),
or?
Second, is it the parameters - or their values - that must be
used?
This goes a little bit deeper; I think that what you are doing
here is,
in part, to specify "which values to assign to the different
parameters
from [I-D.ietf-homenet-prefix-assignment]" -- although that
document
is not particularly clear on which parameters form the
interface to HNCP
and to other protocols.
But, the question is, what does it mean to "MUST use the
following
parameters" here? I can see that using these terms/definitions
in
the description of HNCP makes sense, but that does not a "MUST
use
the following parameters" make.
So, I simply do not understand what you intend with 6.2.1.
o Section 6.2.2, 6.3, etc....
This links in with previous comments regarding the hierarchy and
location of protocol elements. The TLVs defined herin, are they
"top level TLVs" or are they sub-TLVs, to be carried within
another TLV?
And, what's the context of their processing.
This point is particularly obscure since the protocol does not
act
symmetric nor consistent here:
o it defines an "EXTERNAL-CONNECTION" TLV (which
really
is what other protocols would call a
"messagge") which
carries sub-TLVs that have to do with
describing "EXTERNAL
CONNECTIONS".
o But, for Prefix Assignments, it does, as far as
I can tell,
not define a "PREFIX-ASSIGNMENT" message
(apologies, TLV)
which contains the related sub-TLVs
I would like to see this through through -- ideally,
re-engineered to
be homogenous and consistent, but (at the very strict minimum)
called
out and explained clearly.
o 6.2.3. Making New Assignments
"Whenever the Prefix Assignment Algorithm subroutine is run
on a
Common Link and whenever a new prefix may be assigned
(case 1 of the
subroutine), the decision of whether the assignment of a
new prefix
is desired MUST follow these rules: "
Hold on there for a second:
1) What is "the Prefix Assignment Algorithm
subroutine"? Throw a
citation into
[I-D.ietf-homenet-prefix-assignment] here, so
the random reader knows what you're talking
about -- and, a
section reference, also.
2) This is exacerbated by the fact that the
descripton pointing to
"case 1 of the subroutine".
I guess that that correspinds to "bullet number
1" on page 9
in [I-D.ietf-homenet-prefix-assignment], but in
a proposed
standard, guessing should not be needed.
3) <general rant>
That aside, subroutines are programming
constructs, not
specification elements. Just out of spite, I'll
go implement
HNCP using GOTO's instead of "subroutines"
</general rant>
4) I notice that sometimes this is called the
"Distributed Prefix
Assignment Algorithm", at other times "prefix
assignment algorithm”,
then "Prefix Assignment Algorithm subroutine",
etc.
o Are they all the same?
o If yes, then why are they
written, and capitalized,
differently?
o If no, then what're the
differences between them?
Next, the document reads:
"If the Delegated Prefix TLV contains a DHCPv4 or
DHCPv6 Data TLV,
and the meaning of one of the DHCP options is not
understood by
the HNCP router, the creation of a new prefix is not
desired.
This rule applies to TLVs inside Delegated Prefix TLVs
but not to
those inside External Connection TLVs."
What does "is not desired" mean?
"...a new prefix MUST NOT be created?"
"...a new prefix SHOULD NOT be created?"
"...a new prefix MAY be created, but is not necessary?"
The document reads:
"If the remaining preferred lifetime of the prefix is 0
and there
is another delegated prefix of the same IP version
used for prefix
assignment with a non-null preferred lifetime, the
creation of a
new prefix is not desired."
Suggest replacing "non-null" by "non-zero" -- but, beyond that,
what
does "is not desired" mean?
Same comment for the next paragraph:
"Otherwise, the creation of a new prefix is desired"
Am I right in reading these three paragraphs as:
1) If <condition1> then new prefix MUST
NOT be created
2) if <condition2> then new prefix MUST
NOT be created
3) Otherwise, if <condition 3> then new
prefix MUST be created
That is how the text reads, which begs the question:
Is it possible for <condition1>, <condition2>, and
<condtion3>
to all not be satisfied, and what happens in that case?
I *think* that this is a case of underspecification, or at
least where
it looks like there's a case of underspecification.
o 6.2.4:
"MUST create an appropriate route ..."
What's "an appropriate route"?
Do you mean "install entry into the routing table", or do you
mean to
launch a routing process to discover, calculate, or otherwise
obtain
that route?
Do you need the entire path, or just the "next hop towards ..."?
o 6.2.6
"When an HNCP router receives a request for prefix
delegation ..."
OK, how does a HNCP router receive such a request? Grepping
through the
document fpr "request" I see no protocol signals that
correspond to
this.
Then, this:
"The assigned prefixes MUST NOT be given to clients"
made me wonder what a "client" is. I see DHCPv6/v4 client used,
occasionally, and in other places I see just "client" -- is this
intentionally, and, if so, what is a "client"?
o 6.3
"Nodes MAY, at any time, try to reserve a new address
from any
applied Assigned Prefix"
What is an "applied Assigned Prefix". Given capitalization, it
is an
"Assigned Prefix" that is applied somewhere, I suppose, but
where and
to what?
The document reads:
For any assigned prefix for which SLAAC cannot be used,
the first
quarter of the addresses are reserved for routers HNCP
based address
assignments, whereas the last three quarters are left to
the DHCPv6
(resp. DHCPv4) elected router (Section 10 specifies the
DHCP server
election process). For instance, if the prefix
192.0.2.0/24 is
assigned and applied to a Common Link, addresses included in
192.0.2.0/26 are reserved for HNCP nodes and the remaining
addresses
are reserved for the elected DHCPv4 server.
Why "the first quarter"? It seems a rather arbitrary value? Is
it known
to be enough/too much/too little?
"HNCP routers assign themselves addresses using the
Node Address
TLV"
OK, but...do they send that TLV to themselves? Or do they send
it to
someone else, or ...?
Part of the answer to this question is embedded in the text
below the
picture in section 6.3, but not all -- and, I believe, this is
potentially another problem of more global scope.
Generally, for each message (or TLV) it's good to know how it
is formatted, but it's fantastic to know also how it's generated and
how it is processed. I fali to find that (through and through)
in this
document, and that makes it harder to implement.
Would it be possible to do something like this, (generally, for
the TLV
types defined?):
Section X. FOOBAR TLVs
<description>
Section X.1 Generation
A FOOBAR TLV is generated when a, b, c happens.
When generating a FOOBAR TLV, its content is
determined as
follows....
Section X.2 Processing
On receiving a FOOBAR TLV, take the following
steps ...
That would also be the place (in X.1) to state where
to put information (for example, when a TLV must be inside
another TLV)
or constraints on processing (X.2) for example if a TLV is
invalid
unless if contained inside another TLV.
o 9 Securing Third-Party Protocols
I take issue with the below:
"Pre-shared keys (PSKs) are often required to secure
IGPs and other
protocols which lack support for asymmetric security."
Pre-shared keys are chosen, in some scenarios and for whatever
reasons,
regardless of the capacity of the underlaying protocols -- even
when
the protocol(s) (IGP or otherwise) are fully capable of and
completely
supports assymetric security. Please address this by a less
broad claim
for when PSK are used.
But, I wonder, reading this section as a whole: you generate,
and
distribute through HNCP, a PSK? So all it takes to get access
to said
key is to sit by and passively listen to traffic for a bit?
That does strike me as a dangerous option to have...reading the security
considerations section, there seems to be nothing securing HNCP
against
eavesdropping -- or, if there is, that's not called out.
I note that the security considerations of DNCP start out by
saying:
"If specified in the DNCP profile, either DTLS
[RFC6347] or TLS
[RFC5246] may be used to authenticate and encrypt either
some (if
specified optional in the profile), or all unicast traffic"
And, section 3 of HNCP states:
o HNCP unicast traffic SHOULD be secured using DTLS
[RFC6347] as
described in DNCP if exchanged over unsecured links. UDP
on port
HNCP-DTLS-PORT is used for this purpose. A node
implementing HNCP
security MUST support the DNCP Pre-Shared Key method,
SHOULD
support the DNCP Certificate Based Trust Consensus and
MAY support
the PKI-based trust method.
Note the "SHOULD" and the conditonals "unsecured links" (not
sure
what this would be, precisely). I do not know anything
meaningful about
DTLS, but I would imagine that sking the SEC-DIR folks about
its use
would make sense.
All that said...sadly, in many conditions and scenarios
"getting
security to work is hard" and in a home scenario the choice (to
minimize
the amount of support calls, ...) it would not be hard to
imagine either
turning OFF or using lowest-common-denominator security.
Say "nothing" over an Ethernet "because physical access
required", and
WEP for WiFi (yes, people still do that) and then declare links
"not
unsecured" and therfore consider it legitimate to not implement
the SHOULD.
Effectively, what I fear here is that if HNCP "proposes to
share PSKs"
then a (slightly naive) process might actually trust those PSKs
to be
useful for security -- which, in fact, they are not since they
can be
exposed by simple eavesdropping?
I'd really like a bullet-proof guarantee that any shared PSKs
can't have
been (easily) eavesdropped on -- or, would ratehr that HNCP
does not
tempt the use of compromized PSKs.
o Section 10
What's the solution if the message format changes? For example,
that the
type field needs to grow/shrink?
I've mentioned this in my DNCP review, but I strongly believe
that it is
required to have versioning also capture "the frame format",
and not
just the "payload".
Minor Issues:
o General comments:
o I recommend using "non-zero" when referring to
numerical values,
and not "non-null"
o Abstract
Questions: is it clear what "naming" referres to? Is it "name
resolution"?
Idem for "network borders", do you configure those, or
discover those?
Routing-specific question here:
What does "seamless use of a routing protocol" mean?
That any IP
routing protocol can be used unmodified? I *think* that
that's not
the case, given that the use-case that is often trotted
for homenet
includes a multi-homed home - and the introduction says
as much so
the abstract probably should reflect that.
How about somehting like this for the abstract:
"This document describes the Home Networking Control
Protocol
(HNCP), an extensible configuration protocol and a set
of requirements for home network devices. HNCP is described as a
profile of and extension to the Distributed Node
Consensus Protocol (DNCP). HNCP enables automated configuration of addresses,
name
resolution, discovery of network borders, and the use
of any
src-dest-routing capable routing protocol.
o Introduction
"HNCP synchronizes state across a small site in order
to allow..."
What precisely is a "small site"? Can we qualify that in terms
of, say,
number of routers?
"The protocol enables use of border discovery"
I am not sure that I understand what this means -- in which way
is
border discovery *enabled*? Or, do you mean "This protocol
discovers
borders"? Or something else?
"naming and other services across multiple links."
So, the first paragraph teaches me that HNCP is applicable
somewhere not
too big -- but, of course, I do not know what exactly that is
-- , and
it does "some stuff, and other services" -- but, of course, I
do not
know what those are, or how they are characterized. That's a
little
imprecise for an introduction.
Suggest being extremely precise. Something like:
HNCP "Synchronizes state" by way of [dncp], and
specifies and uses
state for providing the following network services:
o FOO
o BAR
o FOOBAR
All specified in this document. Additionally, HNCP
enables other
services, characterized by ______, for example prefix
assignment as
defined by [I-D.ietf-homenet-prefix-assignment]
Which brings me to a question. The abstract, and introduction,
state
that HNCP "enables automated configuration of addresses" -- how
is that
different from [I-D.ietf-homenet-prefix-assignment]? Or, is the
answer
"it isn't, that I-D is required to do that", in which case what
does it
mean that HNCP "enables" it?
[Of course, reading the document it becomes clear that HNCP
does this
by way of a normative reference to
[I-D.ietf-homenet-prefix-assignment],
but the abstract and introduction really are unfortunately
phrased]
Reading just the introduction, I'd like to be able to know what
HNCP
would bring me, exactly? Implementing and turning on HNCP would
do what
to my network?
o 3. DNCP Profile
"HNCP is defined as a profile of DNCP..."
Is it not more correctly to say that"
"HNCP is a profile for DNCP..."
?
"HNCP routers MUST assign a unique 32-bit endpoint
identifier to
each interface for which HNCP is enabled."
Any additional requirements to that identifier? Reading into
DNCP, that
is actually not entirely clear there. I *think* that the
endpoint
identifier MUST be unique to the local node, but that there's no
requirement beyond that -- correct?
Could that be called out both in this document, and perhaps in
DNCP more
clearly?
Following the above:
"The value zero is reserved for internal purposes."
What internal purposes would that be? Reading through, hidden
in the
description of the frame format (6.2.2) I read:
"The endpoint identifier of the local interface
that belongs to the Common Link the prefix is assigned to,
or 0 if
the Common Link is a Private Link (e.g., when the prefix is
assigned for downstream prefix delegation)."
OK, so leaving that slightly odd phrasing (and the notion of
"Common
Link" and "Private Link" -- both of which we will come back to)
for a
later comment, can we not bring this up to section 3, thus:
"HNCP routers MUST assign a 32-bit endpoint identifier,
unique to
the local node, to each interface for which HNCP is
enabled. The
value zero MUST NOT be used, except as endpoint
identifier for an
interface towards a Private Common Link"
?
[but, I am no great fan of "Private Link" or "Common Link", see
other comments]
About this:
"Received datagrams with an IPv6 source or destination
address which
is not link-local scoped"
How about:
"Received datagrams where either or both of the IPv6
source or
destination address is not link-local scoped"
?
As a general comment, this section contains an unordered set of
bullets,
where a grouping and some common discussion probably would make
sense.
For example, a few concern security directly (e.g., 3 & 5) but
are not
really DNCP parametrizations -- whereas others are (e.g., 6, 7,
8).
The bullet-set reads somewhat like "the kitchen sink".
(Numbers indicate count from the first bullet in the block).
o 5. Border Discovery
The document reads:
"A router MUST allow setting a category of either
auto-detected,
internal or external for each interface which is suitable
for both
internal and external connections. In addition the
following
specializations of the internal category are defined to
modify the
local router behavior:"
What defines if an interface is "suitable" for an external, or
internal,
or both, connections? What does "connections" mean in this
context? What
requirements are there for an interface to be "suitable"
respectively
"unsuitable"?
As part of the discussion of the different categories, some are
declared
as SHOULD, others as OPTIONAL. I do not see any which are MUST.
I see
that the two SHOULD should be MUST
Also:
Hybrid category: This declares an interface to be
internal while
still running DHCPv4 and DHCPv6-PD clients on it. It is assumed
that the link is under control of a legacy, trustworthy non-HNCP
router, still within the same network. Detection of this
category
automatically in addition to manual configuration is out of
scope
of this document. Support for this category is OPTIONAL.
What makes a router "legacy"? What makes it "trustworthy"?
o In section 6.1.2 I see:
"Nested TLVs: Other TLVs included in the Delegated
Prefix TLV and
starting at the next 32-bit boundary following the end
of the
encoded prefix:"
"Prefix: Significant bits of the prefix padded with
zeroes up to
the next byte boundary."
Question:
Other than "because historically that's how we did
things,
because, at the time, that was a good idea", is there
any good
reason that you're insisting on byte/32-bit alignments
here? It's
been a good while since I've personally written code
where 32 bit alignment was a major concern -- but, when generating a packet I
sure could see it as a minor nuisance to do the
alignment.
So, I actually see this as "a nuisance introduced in
packet
generation, for no real gain in parsing".
(Note that this is in the MINOR category, though)
o 6.2.3:
"In any case, a router MUST support a mechanism
suitable to
distribute addresses from the considered prefix if the
link is
intended to be used by clients. In this case a router
assigning an
IPv4 prefix MUST support the L-capability and a router
assigning an
IPv6 prefix MUST support serving router
advertisements. In
addition if an assigned IPv6 prefix is not suitable
for Stateless
Address Autoconfiguration the router MUST also support
the
H-capability as defined in Section 10.
To your credit, you put a forward pointer to Section 10. With
that being said, would it not be more logical to discuss that (which appears as
"the overall message format of HNCP") somewhere earlier?
Nits:
o Any reason why some TLV types are written in ALL-CAPS whereas
others in
Hyphenated-Camel-Case?
o I saw a few "e.g." and "i.e.", which I believe the style guide
prescribes should be "i.e.," and "e.g.,". Yeah, the RFC Editor
will
catch this ultimately, but if you re-spin the document then
might as
well make their life just a bit easier ;)
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
