[Ecrit] Re: Comments on ecrit-mapping-arch

[Henning Schulzrinne <hgs at cs.columbia.edu>]

Richard,

I'll start with some answers, in bits and pieces.


On Dec 4, 2006, at 1:03 PM, Richard Barnes wrote:

> 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?

The basic architecture is similar, but the absence of root servers is  
a design decision to make deployment easier even if there is no  
global coordination body. I rather not create another ICANN or task  
the ITU with running a root. We've seen how "well" this works, more  
recently, for ENUM, and so I'd rather provide the flexibility of not  
needing a single (logical) root server.


> 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.)

That's probably a lack of specificity in the architecture. The  
current assumption is that you could indeed have service-specific  
trees. It's not quite clear to me yet whether we need anything  
fancier than whole-subtree mechanisms (e.g., advertising service:sos  
would include all emergency services, while service:sos.police would  
be just the police.)



> 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.

See above. I think in the long run, you need either a consortium that  
restricts access to peering or signatures, so that the consumer of  
the information can decide whom to trust. Given the lack of  
deployment experience, I don't want to prejudge the outcome of that  
debate. There are several possibilities:

(1) consumer choice, based on signed announcements ("As carrier X, I  
only trust announcements signed by CAs A, B and C"), where 'consumer'  
is more likely a VSP-operated resolver than an individual

(2) virtual root, through a signing mechanism ("The global  
association of restaurant guides signs the FG announcements")

(3) peering among FGs requires cooperation; thus, a group of FGs  
could decide to limit membership in their "club" to trusted members.

Again, this seems like a "layer 9" discussion, where I don't claim to  
have a good answer. It also seems likely that different services  
might take different approaches. For some, a fairly loose mechanism  
that kicks out misbehaving
FGs might be perfectly fine, since the stakes are low.


> 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.

See above.


> Cheers,
> --Richard


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