Subject: [Anima] review of draft-jiang-config-negotiation-protocol-02

From: Rene Struik <[email-masked]>
Date: Wed, 17 Sep 2014 15:14:29 -0400

Dear colleagues:

Please find below my initial comments on 
draft-jiang-config-negotiation-protocol-02

1. Summary:
The draft discusses a generic two-part configuration discovery and 
negotiation protocol aimed to be used as a reusable component of an 
autonomic infrastructure.

2. General comments:
a) Rather than having a negotiation protocol between two devices, one 
might as well use a synchronization protocol instead, where both devices 
synchronize information of
mutual interest. If one device does not have current info, this 
automatically could result in pushing the lacking info onto the device. 
(NOTE: see also same general comment #d on review of 
draft-jiang-config-negotiation-ps-03.)
b) The "negotiation" protocol should practice "separation of concerns" 
(e.g., provide core protocol functionality of a configuration scheme, 
where the data elements to be
configured are orthogonal to the core scheme). The protocol should also 
be as independent of routing protocol dependent features, including 
addressing that may
correlate with network topology (since contrary to the objective of 
being a reusable block without all these interdependencies that increase 
complexity). (NOTE: see also same general comment #e on review of 
draft-jiang-config-negotiation-ps-03.)
c) The negotiation protocol should consider in its design 
privacy-related aspects, no just in exchange of configuration-relate 
data, but also with "outsourcing" counter part functionality (as 
suggested in Section 3.3, top of p. 6).
d) Heterogeneous trust domain use cases should guide the design 
(contrary to what Section 11 claims)

3. Specific comments:

Section 1:
1) Second para: it is unclear why the assumption is made that each 
network device has a hierarchical superior (this is not even possible, 
since the set of devices is a finite set). If this assumption is 
essential, this greatly reduces the appeal of the protocol design, since 
again making network topology related assumptions (something autonomous 
networking was supposed to side step where possible, so as to reduce 
complexities in current network management approaches). The last 
sentence of this para seems to indicate that this assumption is not 
necessarily, though. If so, please remove!
2) Third para: it is unclear how the CDNP scheme presented in the draft 
can be used to implement control decision processes between networks. 
The protocol seems to be a device-to-device protocol, so the most one 
can achieve is some negotiation between (single-device) representatives 
of different networks (no matter how one codifies this "representative" 
notion).
3) Fourth para (bottom of p. 3):  One should take into account "managed 
change", co-existence of new systems with pre-existing ones (something 
that applies to any development), so should add some verbiage as to how 
to cater to mixed deployment settings, where the CDNP scheme proposed in 
this draft is not universally implemented (even if this is only during 
initial roll-out).

Section 2:
4) Second bullet: devices do not generally spontaneously start discovery 
(at least, not to my knowledge). As an example, with IEEE 802.11 or IEEE 
802.15 networks, this may be triggered by receiving a beacon message 
from a router or other network component.
5) Third bullet: isn't the "negotiation counterpart" usually called the 
"respondent"? (Note: I am mostly familiar with security specification 
verbiage, where one usually specifies protocols in terms of 
initiator/responder interactions.)
6) Fourth bullet: while it is certainly possible to identify a device by 
a device-specific public key, this is certainly not the only way (and 
may trigger questions as to persistence, what happens if a device does 
not have a key yet or this key changes). (NOTE: The general area of how 
to identify nodes seems to require more thought, since this notion comes 
up over and over again in IETF NMRG drafts, with imprecise definition of 
what one wishes to accomplish, privacy aspects, and general device 
lifecycle management aspects. I do think that manufacturing devices so 
as to allow authentication via public-key based techniques has lots of 
merit, last but not least being that it reduces trust lifecycle 
management to the management of device identities, but this certainly 
requires somewhat more thought re details. {This note is tangential to 
the negotiation protocol per se, but I just put this in, so that we do 
not forget to explore this further.})

Section 3:
7) First sentence: replace "platform" by "scheme" (I don't think a 
protocol is a platform).
8) Second para: There should be some discussion on the impact of 
device-to-device negotiation protocols on the global state of the 
system. After all, the order in which local two-device negotiations take 
place may have an impact on more global state changes (e.g., if the 
configuration parameter dependencies form a cycle in a graph 
[synchronization of time parameters comes to mind, here]). (NOTE: this 
is the same remark as general comment #c on review of 
draft-jiang-config-negotiation-ps-03).
9) Second para: Isn't the negotiation protocol supposed to be a 
peer-to-peer protocol, or is the nuance between initiator/responder and 
peer-to-peer so small one could use this interchangeably?
10) Second para: the current para seems to suggest that what is 
negotiated is triggered by a request by the initiator. What about making 
this mutual, where the two entities involved mutually negotiate 
configuration parameters based on data elements of common interest. This 
ties into general remark #a above, where one simply makes this into a 
mutual synchronization scheme.
11) First para: if one tries and be IP-version agnostic, this may mean 
that one cannot assume specific notions, such as cryptographically 
generated addresses (CGA) that are only available in IPv6. Shouldn't one 
finally cut the cord and simply not deal with IPv4 considerations (one 
cannot drag the entire history of the universe forward infinitely!).
12) Section 3.2, second para: Sometimes, the initiator of a negotiation 
protocol does not need to discover its partner in crime (see, e.g., 
remark #4 above).
13) Section 3.2, second para: Negotiation protocols may result in 
exposure of lots of privacy-sensitive information (and allow 
traceability of devices). I think some of this needs to be explored in 
more detail in this draft (currently, privacy is not mentioned at all). 
A parallel with TLS-related discussions comes to mind here, where 
question was to encrypt or not encrypt SNI information. There seem to be 
lots of use cases of discovery protocols where one does not necessarily 
want to expose (at least not wirelessly) the nature of a discovery or 
the identity of the parties involved.
14) Section 3.3, last para of p. 5: It is unclear why the responder 
starts the actual negotiation process. Shouldn't one consider the 
responder's message as the second protocol flow of a scheme instantiated 
by the requester in the first place? It seems that having the responder 
initiate the negotiation add more protocol round-trips than necessary 
(and also seems to suggest that the first and second protocol flow are 
logically decoupled, rather than offering the requestor assurances that 
flow #2 is cryptographically tied to flow #1).
15) Section 3.3, first para of p. 6: The outsourcing of counter part 
functionality may have privacy implications ("gossip" behavior) and may 
potentially result in denial of service attacks and message storms. This 
seems to require lots more careful consideration.
16) Section 3.3, end of first para, p. 6: The notion of having to rely 
on a hierarchically upstream device seems highly unattractive (see also 
remark #1 above).
17) Section 3.4: the cert-based security mechanism tenets (bullet items 
1-3) seem to suggest a signature-based approach, where counters provide 
for replay protection. While signed messages can indeed provide for 
source authentication and authorization check of the originator (policy 
enforcement), this seems to be a somewhat adhoc approach: why not make 
the protocol into a real cryptographic challenge response protocol, 
where protocol flows are logically tied together, where one gets 
timeliness for free, etc.???
18) Section 3.4: the second para (after the bullet list) seems to 
suggest an operator-run CA model. Hooray: another mechanism for 
operators to lock-in customers (this time under the pretext of 
security)! This seems to be counter to consumer interest and "network 
management neutrality" (as I argued during the ITF-90 BoF session in 
Toronto). Moreover, this is also counter to flexibility in design 
considerations, where the operator of some trust functionality could be 
completely orthogonal to the operator of a/the network.
19) Section 3.4, second para: in my mind, the suggestion that a 
negotiation protocol run by an operator, that for a small office or for 
a home network are different design exercises seems to be a very bad 
omen. I thought the objective was to design a generic negotiation 
protocol (see draft-jiang-config-negotiation-ps-03), where the exchange 
data elements would be orthogonal to the core functionality. I fail to 
see why one cannot design a single protocol that could cater to all 
these cases, without lock-in by design. One can very well design 
flexible schemes, where only the instantiation may be different 
depending on deployment scenario.
20) Section 3.4, third para: The mechanism described here exposes lots 
of privacy- or traceability-related information; moreover, it is hard to 
assess the storage requirement ramifications of "certificate stores". (I 
keep musing about whether mechanisms defined would be useable in 
constrained network settings.)
21) Section 3.4, first para on p. 7: the public key sizes seem to 
suggest RSA keys. I am hoping that we only use ECC-based keys anno 2014 
(which have a far more modest size: 32 bytes for 128-bit crypto strength).
22) Section 3.4.1: this entire section can be summarized as as follows: 
(i) a mechanism for protocol version control is [should be] provided; 
(ii) a mechanism for identification of crypto algorithm suites to be 
used with an instantiation of a specific protocol is [should be] 
provided. Note: right now, item #(i) is not described in the text. BTW - 
I am not a big fan of having yet another protocol where one provides a 
"Chinese menu" set of options (to use Peter Gutmann's phrase). We should 
pick a strong default, root out anything suspicious/low-grade, and stick 
with it if at all possible. All this "option-itis" is completely counter 
autonomous network and in conflict with allegiance to having fewer 
configuration options (as proclaimed in Section 5.3 of 
draft-irtf-nmrg-an-gap-analysis-01).
23) Section 3.4.1, third para: the last sentence seems to mix design 
philosophy and security policy enforcement details. It is unclear why, 
again, one tries to bring in network topology related factors in a 
design that is supposed to be generic and, while doing it, even 
hard-codes security policies.
24) Section 3.4.2, second para: replace "authority" by "authenticity".
25) Section 3.4.2, third para: it is unclear what the storage impact of 
the local trust cert records are. This seems to be a design choice that 
requires more study, since seemingly trading state vs. computational cost.
26) Section 3.4.2, firs para on p. 8: if signature verification is so 
expensive, this makes me wonder why the protocol uses an ordered 
sequence of signed messages in the first place. Why not look at less 
costly provisions? (See also remark #17 above).
27) Section 3.4.2, first para on p. 8: the entire protocol design seems 
to depend on having a trusted clock on each device, which (in my mind) 
is an unrealistic assumption (this is my perspective on the question 
posed in Section 10, last bullet of p. 21), and leads to lots of 
complications due to clock skew (see the entire Section 3.4.3). Why do 
through all this trouble with an adhoc protocol, instead of simply using 
well-known mutual challenge response protocols that have been 
well-studied, have clear security properties and do not require clocks 
(at least not for this purpose).
28) Section 3.4.3: the procedure for preventing replay attacks by 
checking last kept time info seems to be insecure: what happens if one 
has t1 < t2 and one receives info in sequence t1, t2, t1 or t2, t1, t1?
29) Section 3.5, second para: replace "confguration" by "configuration"
30) Section 3.5, second para: this para suggests that the normal course 
of action is a one-sided configuration protocol. If so, isn't that case 
already covered by DHCP? I think the entire design should be a mutual 
protocol with strong cryptographic assurances (including that of 
timeliness, authentication, etc.) and with (orthogonal hereto) 
possibility to exchange data elements of mutual interest to one's 
heart's content. These strong assurances should not be watered down even 
if some corner cases may allow this in the case only unilateral 
configuration is required.

Section 4:
31) Why would there be a need for new address info, rather than using an 
addressing mechanism already defined? (To me, this sounds like a sure 
way to realize very slow adoption with any device that does not 
recognize the newbee address yet.)

Section 5:
32) Second para: The mechanism by which root certificates end up with 
devices and by which certificates are generated and distributed is not 
described. This requires more work, esp. since there is lots of protocol 
design work where this aspect has been ignored or not paid sufficient 
tribute to, thereby preventing wide-scale adoption. Public key 
technologies only find wide-spread use if the entire lifecycle can be 
implemented in a secure, flexible, scalable, and low-cost way.
33) Last para, p. 11: replace "SHA-1" by "SHA-2" (one does not wish to 
use crypto constructs that have been on the "to be depricated" list 
since 2005 in new protocol design work anno 2014).
33) last para, p. 11: replace "hash algorithm" by "hash function".

Section 6:
34) The motivation for introducing session identifiers is missing. In 
particular, it is unclear whether this is motivated by security 
considerations or, e.g., by desire to segregate different instantiations 
of the protocol. {Note: since it is unclear (to me) what the claimed 
security properties of the protocol are, it is hard to assess at this 
point (although, I could try and guess here of course)}

Section 7:
35) First sentence: replace "vaiable" by "variable".
36) In device tag description (p. 12), replace "deviceas" by "devices".
37) In options description (p. 12), replace "definded" by "defined".
38) The description of the Request message seems to suggest the use of 
the unicast address of a known "counterpart" (if known). This begs the 
question whether this unicast address is independent of network topology 
considerations (for otherwise, one gets dependencies one wishes to avoid 
in again via the addressing back door).
39) With Section 7.4, it is unclear why one needs this message. Isn't 
the negotiation ending message superfluous (it certainly seems to be, 
from purely cryptographic perspective, but I may have missed something 
here).
40) With Section 7.5, the Confirm-Waiting message description seems to 
suggest that recursive layering is possible. It would be good to 
investigate whether this has a negative impact on state machines and, 
e.g., local storage cost.

Section 8:
41) In Section 8.7, the algorithm identifiers (HA-Id, SA-Id) seem to be 
unwieldy (2 octets each). Moreover, the only choice should be a profile 
choice as to signature scheme (e.g., ECDSA-P256-SHA-256). Listing these 
ids separately seems an invitation to "Chinese menu" afficionados to 
bring in a complete Cartesian product of optional behaviors. Since 
interoperability and desire for automatic behavior is aimed for, this 
tendency should be rooted out.
42) Timestamps could be avoided with a properly designed challenge 
response protocol (see also remark #27).
43) All options in Section 8.8 onwards seem to be specific encodings of 
data elements that are not common for the core protocol (these can be 
viewed as extensions to serve, e.g., routing confirmation material, 
etc.). The draft should more clearly indicate which options are part of 
the core scheme and which are simply encoding of data elements of mutual 
interest to the two entities executing the negotiation scheme.

Section 9:
44) Second para: if the objective options are to be known in the initial 
protocol flow (request message), this protocol is not truly a mutual 
configuration negotiation protocol: mutual protocols depend on inputs re 
desired data elements from the responding party as well.

Section 10:
45) Third bullet: while TLS could be used, this can hardly be called an 
example of simple design (please have a look at the TLS mailing list, if 
one believes otherwise). Moreover, TLS does not offer an easy way to 
synchronize data elements. Or, does one seriously consider to use the 
TLS record layer here???
46) Third bullet: replace "build in" by "built-in".
47) Fifth bullet, p. 21: this is an unrealistic assumption (see remark 
#27 above). Moreover, the topic of providing a secure, loosely 
synchronized clock is not easy to realize, certainly not for devices in 
constrained, spotty networks.
48) Seventh bullet (2nd one on p. 22): replace "uses cases" by "use cases".
49) Ninth bullet item (4th bullet on p. 22): one counter example (in 
application domain) would be a device looking for a wireless printer in 
a business hotel (where there may be more than one).

Section 11:
50) The assumption that CDNP is intended to be deployed in a single 
administrative domain (homogeneous trust domain) is questionable; 
moreover, having to rely on a single CA within a trust domain does not 
suddenly make this an approach that does not require a trusted third 
party (this seems to be a misconception about what the wording "third 
party" means in the crypto and security literature). One should strive 
for a protocol that works in a heterogeneous trust domain setting (where 
the device looking for wireless printer scenario in remark #49 is 
already an example). Even if one ultimately operates devices in a single 
trust domain, this does not mean that none of the settings it operated 
in prior to the operational usage states was heterogeneous. Please, 
please: let us stop thinking in semi-static models of how the world 
operates; one should think any-to-any device mappings with heterogeneous 
networks throughout the *entire* lifecycle of devices and networks.

Section 12:
51) On p. 24, please remove references to SHA-1 and RSASSA-PKCS1-v1.5 
(which, honestly, should be deprecated for now). BTW - even if one still 
would like to use RSA, one should not use the v1.5 schemes...

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363