Hi
I was asked to do a review of the draft-ietf-anima-brski-discovery feedback, so
here it comes. The document is quite lengthy, so is this review, sorry for this.
The reviewed ID was: draft-ietf-anima-brski-discovery-05.
The review below consists of two parts: general comments and editing remarks on
a per-section basis in the detailed comments.
If you have any questions, I remain at your full disposal for further
discussions.
Best
artur
<review>
1. GENERAL COMMENTS
The document is a bit too long and, in my opinion, goes in too many
side-discussions, not necessarily of primary importance for this specification.
The beginning of the document (maybe the entire intro) could be rewritten to
better clarify what this document intends to specify, before discussing why
it's complicated and all the constraints. The essence of this document are the
IANA tables in Section 4 - it should be probably shortened to reflect this. All
other considerations could go into separate "best practice" like drafts.
Notably:
* Clarify early that this document is not proposing any discovery method
per se.
* Give examples of discovery methods, which you believe are suitable for
what is proposed in this document. Personally, I believe giving some concrete
examples early in the text and clarifying what you want to specify would make
the text easier to read.
* Can it not be a DHCP option, in particular for IP/IPv6 based setups?
* Introduction is probably too long. The given argumentation is hard to
understand before the explanations would come. Proxies appear too early in the
text: the document proposes a discovery method for BRSKI, the intro starts
discussing all kinds of issues with proxies. Why?
* The definition of context (or variation context) and the use of it in the
document is overloaded:
* Context or variation context, please use one of the two
* "BRSKI" is both context name and the whole protocol family name
* Clarify reasons for calling it "responder socket" as opposed to using
URI/URL and the formats herein
* Please provide a rationale for choosing some non-standard encoding as
suggested in this text over e.g. JSON.
* Would seem to lack the type-value pair notion, this opens a debate
updateability vs. parsing complexity?
* To be potentially discussed in the security considerations:
* If variants allow for less secure methods, this is a potential
vulnerability (security downgrade attacks, problematic in particular with
proxies)
* For this document to improve chances of picking non-malicious
announcements (s. 3.2.4), it should prioritize the "highest security"
responders, which so far it does not. Otherwise it should prescribe a
sufficiently secure option as default and discuss required validations along
this default mechanism. Specifically in 3.2.4, I am not sure this is useful:
high weights in service announcements are probably as easy to forge, as service
announcements per se.
* Potentially, a "network name" is missing: it would seem that pledge does
not care what it connects to. It just tries to discover *some*, *any*
registrar. Is it always the case? Shouldn't the discovery hint on a name?
* Consider the following use case: physical infrastructure with a dozen
of "virtual networks" that I can pledge to, once I have established a physical
link. The discovery would yield say 20 answers. Yet, with high probability I am
only interested in the 2 redundant proposals (responders, variants) coming from
the actual virtual network that I want to and can connect to. Where is that?
How would it be implemented?
* Detailed considerations for proxies (stateless/stateful, selection,
resilience, etc): not sure that these considerations belong into the discovery
specification like this text.
* Many of these things may not be of primary importance for the
discovery itself, as the discovery does not have to use any proxy whatsoever.
* The opposite also holds: proxies might be useful without any discovery.
* The document becomes too heavy and would be difficult to maintain if
we combine both in one.
* Suggestion: probably, a separate draft, can be considered for these
detailed proxy considerations.
* The current text on proxy considerations per se seems valuable e.g.
for developers, however, it has little to do with the actual discovery
specification of that document.
* This separate draft could summarize best practices for proxies,
i.e., imaginable/common proxy modes, proxy deployment thoughts, proxy vs.
discovery coexistence, recommended proxy behaviour (selection of endpoints,
connection dispatch, etc.) Most of these things do not look like a
specification, but rather as a BP to me.
* Hence: I suggest that these be extracted, put in a different document
and simply referenced in that one.
* Only discovery-specific thoughts with regard to proxies (e.g.
transparent support of new variations, or "arbitrary variation support") could
potentially stay, in particular if the discussion explains the design choices
of the variations, contexts, defaults, etc. made in this document through the
argument of making proxy support simpler. If they rather explain how this
arbitrary variation support can be best implemented in a proxy, it should be
moved to the other document. Note that the selection as such is not
discovery-specific, as a typical proxy could have a preconfigured list of known
registrars as well, as part of its configuration. How to best map N clients to
available K servers within a proxy is a fundamental proxy/gateway problem,
independent of discovery.
* Not sure why the discussion on construction of IDevID and the
verification thereof (3.4.2ff, in particular 3.4.3) should be in this document.
* Same argument as for the whole proxy discussion, the point being:
whether there is discovery, or whether the pledges and registrars are
respectively preconfigured, the identification string construction and its
respective matching remain exact the same. It's not because of the discovery
that these complexities arise.
* Not sure why the discussion on host names in 3.5 is absolutely required.
Isn't it a matter for DNS-SD anyhow, regardless whether it's BRSKI or not?
* Granted, some of the discussed facts are BRSKI-specific. Can we not at
least shorten the text by simply stating these facts? It would streamline the
text. Something like: "BRSI registrars do not need host names". Etc. But the
overall discussion seems a bit off for that draft.
* Current security considerations seem to be rather related to DNS-SD and
less specific to the actual specification in this draft. DNS-SD related
security vulnerabilities do not need to be rediscussed in this draft.
Potentially better security considerations are suggested above.
1. DETAILED COMMENTS
(per section, with section numbers from the draft. s/x/y = substitute x by y)
1. Overview
- s/new use-case preferences may prefer/new use-case preferences may result in
- s/with interoperability, that the mechanisms defined in this document
intent to help sove/with interoperability, which the mechanisms defined in this
document intend to help solve
2.1.1
- s/When an initiator such as a BRSKI proxy or BRSKI pledge uses a
mechanism such as Section 1 to discover an instance of a role it
intends to connect to, such as a registrar, it may discover more than
one such instance./""
o Note: the phrase is present two times, albeit in slightly different forms.
- s/FOr example/For example
- Note: "Different BRSKI deployments may prefer different discovery
mechanisms, such as Section 1, Section 1, Section 1 or others" (check
Sections).
- s/This make it/This makes it
3.1
- s/supporting specific a specific BRSKI role/supporting a specific BRSKI role
- s/whether that responders variation/whether that responder's variation
3.1.4
- s/Todays these are based on whether Section 1 is used or not/Today, these
are based on whether Section 1 is used or not.
o Note: Section 1 is unclear in this context.
3.1.7
- s/This document does also not introduce variation contexts for/Also, this
document does not introduce variation contexts for
o Note: it seems redundant to write "variation context" given the provided
definition.
o A bit later, in 3.1.8 the document says that it introduces variation
contexts in form of IANA tables. Thus, maybe the phrase above should be
reworded to: "This document only introduces variation contexts for specific
roles".
3.1.8.2
- Note: For example, Section 1 specifies the empty string "" as the
objective-value in Section 1 discovery.
o In this phrase, the reference to "Section 1" is unclear. Section 1 of this
document does not have anything of this kind.
3.1.8.3
- Note: "one-off" variation string is not very clear without further
explanations.
3.1.9
- Note: "Section 1" again. Unclear reference.
- /s/dcoument/document
3.2
- s/specific do the target deployment/specific to the target deployment
3.2.1
- s/Inter-DC service redundany/Inter-DC service redundancy
3.2.2
- s/Problems such as a hanging//unresponsible/Problems such as a
hanging//unresponsive
- s/when the responder did/when the responder died
3.2.3
- s/Stateless proxies can not/Stateless proxies cannot
- s/stateless responsivness/stateless responsiveness
- s/service annuncements/service announcements
- s/superceeded/superseded
3.3.2
- s/3.3.2.1. Direction Connections Mode/3.3.2.1. Direct Connection Mode
- s/registrars service announcement/registrar's service announcement
- s/for that pledges connection/for that pledge's connection
- s/registrar sockets it maps to between/registrar sockets they map to between
3.3.2.2
- Note: probably the order of description here should be slightly changed, or
the text should be rewritten slightly - current text:
o It then connects pledges to the best available registrar socket from that
set.
o It then announces this socket with the parameters of the best discovered
registrar socket <...>.
However a proxy does these two things in the opposite order, usually.
- Note: "Stateless proxies can not learn unresponsiveness" the whole
paragraph is a repetition from 3.2.3, verbatim, including typos. Is that
redundant text required?
- Note: the paragraphs just after it are also repetitions from 3.2.3,
largely. Please check, if this cannot be organized differently, maybe rather
re-structure in Considerations for Stateless proxies and Considerations for
Stateful Proxies, and then introduce particularities for registrars and
responder selection accordingly?
3.3.2.3
- s/UDP for connections pledges/UDP for connections from pledges
- s/implementation can not discover/implementation cannot discover
3.3.4
- s/example the common cade of/example the common case of
3.4.
- Note: Section 1 reference again.
3.4.1
- s/can easier enumerate expected pleges/can enumerate expected pledges more
easily
3.4.2
- s/Two different manufacturer/Two different manufacturers
- Note: the serial number refers to the physical device. I am not sure about
the precise use case for BRSKI, but I can easily see an additional problematic
situation, namely, where two or more pledges run on the same physical device.
This can happen, when the physical device with a serial number visible from
outside is some form of bay, collection, host, load-balancer, etc., which
internally has e.g. several line cards, several boards, several storage devices
or whatever. Also, I can imagine an accessing host being a laptop or a
smartphone (BYOD), in which resp. only some particular secure enclave is
supposed to have access. There can be even several such environments, e.g. one
for product line work, and some other for more general admin tasks. These two
would hardly be the same as the physical laptop and have to be distinguished
from each other; besides, the physical laptop might be exchanged e.g. by the
issuing enterprise every 2-3 years, yet the basic software environment might
stay quite unchanged, updates notwithstanding.
3.4.3
- s/use simple numerica/use simple numerical
3.5.1.3
- s/may need to to discover/may need to discover
- s/which printer to to pick/which printer to pick
- s/This requirement exist/This requirement exists
- s/operators are not unnecessary required/operators are not unnecessarily
required
- s/such as a registrar understand/such as a registrar understands
- s/OUI where assigned/OUI were assigned
- s/when they have globals scope/when they have global scope
- s/unique name, is actually unique/unique name is actually unique
- s/names. instance names/names. Instance names
- Note: please review and simplify/correct the following phrase:
o "to pick the same host name requirements based encoding format for both
type of DNS RR nams when using encoded addresses in them"
- s/vendors that usecBRSKI/vendors that use cBRSKI
- s/SRP is useable/SRP is usable
- s/appening some string/appending some string
- s/and it's numeric process/and its numeric process
3.5.2.2
- s/In Figure 5, A separate/In Figure 5, a separate
- s/value that also support/value that also supports
3.5.3.1
- s/Section 1 introduces a stand alone/Section 1 introduces a standalone
- s/In summaery/In summary
- Note: check the "Section 1" occurrences
3.5.3.2
- Note: check the "Section 1" occurrences
- s/assumeption is/assumption is
3.5.3.3
- s/extensions to what was is specified/extensions to what is specified
- Note: check/correct the follow-up phrases:
o "This document does not specifiy how to discover It uses terms"
- Note: there is a requirement (MUST) to register something with IANA. Does
it make sense?
o Shouldn't a specification either register it or assume that it is
registered?
- s/likewise, Additional BRSKI/likewise, additional BRSKI
4.1.2
- s/IANA is asked to add an entries/IANA is asked to add entries
- s/useable/usable
5
- Note: please check the occurrences of "Section 1" again
o "In Section 1, pledges are easier subject to DoS attacks than in Section 1,"
</review>
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
