[Ecrit] Comments on ecrit-mapping-arch

[Richard Barnes <rbarnes at bbn.com>]

Henning,

After reading the latest mapping architecture draft, I have a few 
high-level questions:

1. Relation to DNS: Beyond the distinction you make in section 7.1 
(trees are organized by geography rather than label), how is this 
architecture different from the DNS?  In particular, what value is added 
by the forest guides that wouldn't be by a root server or servers?

2. Role of Services: LoST explicitly maps a request that contains both a 
location and a service to a URI (pointing to the provider of that 
service in that location).  The mapping architecture, on the other hand, 
 seems to say that the heirarchy of tree structure is based only on 
geography, rather than allowing branches based on services.  For 
example, the state police might have their own separate subtree under 
the state-level node that handled the territories of their field 
offices, independently of other emergency services.  In general, how did 
you envision multiple services being located in this architecture? (I 
think that with the current document, there would have to be separate 
by-service trees, or all services for a locality would be stored at that 
locality's leaf node.)

3. FG handling of overlap: I'm worried by the following sentence: "A 
tree node at the top of a tree can contact any forest guide and inject 
new coverage region information into the system."  Within trees, 
impersonation is not as large an issue, since a tree is specified to 
return all results for a given region (because of overlap).  But there's 
no similar specification for FGs: If I set up a tree that directs all 
emergency calls in New York to me and convince a Forest Guide to accept 
it, nothing in the architecture says that my tree won't override the 
existing, legitimate New York tree.  It seems like this would be less of 
an issue if there were some root node that could coordinate trees.

4. Security of Forest Guides: In general, the concept that all FGs have 
the same information seems at odds (1) use of "local policy" for 
admitting maps (as specified in section 9), and (2) the notion of a 
"trusted forest guide".  For example, it seems like a situation could 
arise in which an attacker could feed bad information to a single FG 
with lax policies for admitting maps, and this FG would propagate that 
information to the rest of the FG population.  Since FGs seem to trust 
other FGs implicitly (I don't see any contradiction to this), every FG 
is exactly as trustworthy as any other.

Cheers,
--Richard



_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit