Last Call Review of draft-ietf-alto-protocol-25
review-ietf-alto-protocol-25-secdir-lc-harkins-2014-02-06-00
| Request | Review of | draft-ietf-alto-protocol |
|---|---|---|
| Requested revision | No specific revision (document currently at 27) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2014-02-04 | |
| Requested | 2014-01-23 | |
| Authors | Sebastian Kiesel , Wendy Roome , Richard Woundy , Stefano Previdi , Stanislav Shalunov , Richard Alimi , Reinaldo Penno , Y. Richard Yang | |
| Draft last updated | 2014-02-06 | |
| Completed reviews |
Genart Last Call review of -25
by
Martin Thomson
(diff)
Genart Last Call review of -25 by Martin Thomson (diff) Secdir Last Call review of -25 by Dan Harkins (diff) Opsdir Last Call review of -25 by Jürgen Schönwälder (diff) |
|
| Assignment | Reviewer | Dan Harkins |
| State | Completed | |
| Review |
review-ietf-alto-protocol-25-secdir-lc-harkins-2014-02-06
|
|
| Reviewed revision | 25 (document currently at 27) | |
| Result | Has Nits | |
| Completed | 2014-02-06 |
review-ietf-alto-protocol-25-secdir-lc-harkins-2014-02-06-00
Hello,
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
This draft defines a protocol that allows a server to provide network
location information, network structure and network cost/preference
to a client which then can build an abstract view of the network in
order to determine how best to use it.
This draft is "ready with nits" (per secdir review instructions). And
those nits are:
- 6.1.1.1 mixes the idea of "cost" and "preference". While it's
natural for people to prefer lower cost I think it would be better
to say so explicitly: "A lower value indicates a lower cost" or
this field "conveys a generic measure indicating preference for
routing traffic from source to destination" or something like
that.
- 6.1.2, while a particular Cost Map may contain only one of the
two cost modes, servers MUST implement support for both,
right? It's not clear from the text.
- 6.3, since the tag must not contain ASCII characters below
0x21 or above 0x7e you can't really construct one from the
hash of the contents of a Network Map. Also, given those
restrictions and the fact that a tag just has to be less than
or equal to 64 octets, the probability of identical tags being
used is not zero. I think the probability of the tag from
example 11.3.1.7 is 0.5 to collide with one of just 460
other Network Maps.
I suggest requiring a tag to be 64 octets. That will make
even money probability of collision among nearly 3000
other Network Maps, which is safer.
- 8.3.5, encryption and integrity protection go hand-in-hand,
they cannot be "and/or". Suggest changing the sentence to
"When confidentiality and data integrity between client and
server are required, and server and/or client authentication
is required?." This section should refer to section 15 (Security
Considerations).
- 11.3.2.6, what does it mean for a Version Tag to be
"consistent with" another Version Tag? Do you mean that
they are "identical"? Same length and same value? Or would
"0004579342" be "consistent" with "4579342"?
- 15.3.1, the ALTO data can be sensitive since it includes
things like endpoint addresses (useful for those who like
to monitor the Internet). I think risk (2) here should include
mention of that. There may be classes of ALTO data for
which certain clients are authorized to receive and others
are not.
- 15.3.2, the Security Considerations section seems an odd
place for normative language-- "HTTP Digest authentication
MUST be supported". I suggest finding a more appropriate
place, perhaps 8.3.5, to spell out normative requirements.
Also, authenticating the client in the TLS exchange would
be much preferable and I think mention should be made
on that option. I think differentiated authorization (see
my previous comment) would be easier this way too.
- 15.4.2, authorization of an authenticated client is another
useful protection strategy here-- some client's may get
obfuscated data, and some may get the raw data.
I think the Security Considerations are well done.
regards,
Dan.