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

From: Richard Barnes <[email-masked]>
Date: Mon, 04 Dec 2006 13:03:13 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 4 Dec 2006 23:19:28 -0500

Richard,

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

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

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