Subject: [Ecrit] LoST recursion and Forest Guides

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 17 Jul 2013 19:10:22 +0000

An issue arose in a NENA discussion that calls into question the RFC5222, Section 8.3.3 text that reads:

   Regardless of the attribute, a server MAY always answer a
   query by providing a LoST application unique string (see Section 4<http://tools.ietf.org/html/rfc5222#section-4>),
   i.e., indirection; however, it MUST NOT recurse if the attribute is
   "false".

Imagine that an area has a local LoST server that answers local requests, and that server is aware of a regional or state/provincial server, which in turn is aware of a national forest guide.

Suppose a request to a local server has a location which is out of state/province.

If the 'recursive' attribute is missing or set false, the local LoST server would return the URI of the regional or state server.  The regional or state server would return the URI of the national forest guide.

This means that the national forest guide must be prepared to answer queries from any device at any time.  In particular, it has to be sized for the worst case scenario where a very large number of devices make requests of it, and it cannot refuse a request from any source (as a practical matter).  This makes it a very attractive DDoS target.  In fact, I would argue that a great number of implementations will simply start all queries at the top of the tree in all cases, since the forest guide URI will become well known quickly.

This is very undesirable in my opinion.  Instead, we should allow the local and/or state/regional LoST servers to query the Forest Guide and return the response.  This would allow the Forest Guide to restrict who is able to query it, possibly to only those entities that provide it coverage regions, or some similar smaller set of queriers.

What prevents us from doing that is the requirement that the server MUST NOT recurse if the attribute is missing or set false.

I would actually like to go farther.  I'd prefer that the state and possibly the regional LoST servers be able to restrict who can query them, for the same reasons.

I would like all queries to start at the local server, and allow that server to recurse, if it prefers to, regardless of the attribute.

Brian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Jul 2013 10:27:50 -0700

On 17 July 2013 12:10, Rosen, Brian <[email-masked]> wrote:
> I would like all queries to start at the local server, and allow that server
> to recurse, if it prefers to, regardless of the attribute.

Isn't it always possible for a server to decide to recurse, regardless
of what the client and some moldy RFC says?

Maybe you can write an update to said moldy RFC and we can all
rubber-stamp it.  What you describe is a reasonable operational
practice.  At one point, we talked about cases where the higher level
LoST servers wouldn't even be accessible from the public Internet,
always requiring intermediated access from known "proxy" servers.

---

From: Karl Heinz Wolf <[email-masked]>
Date: Mon, 22 Jul 2013 10:55:26 +0200

On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <[email-masked]>wrote:

>
>  This means that the national forest guide must be prepared to answer
> queries from any device at any time.  In particular, it has to be sized for
> the worst case scenario where a very large number of devices make requests
> of it, and it cannot refuse a request from any source (as a practical
> matter).  This makes it a very attractive DDoS target.  In fact, I would
> argue that a great number of implementations will simply start all queries
> at the top of the tree in all cases, since the forest guide URI will become
> well known quickly.
>

Brian,

I got a bit confused here and I probably missed the discussion on the
issue. However, the mapping architecture in RFC 5582 describes that a
seeker queries a resolver, the resolver consults a forest guide and then
goes to the root of the appropriate tree. So I don’t see how the RFC5582
architecture should work without the forest guide URI to be known by
resolvers. Moreover, since the forest guide points to the root of the tree,
the query has to start at the root. Or are you talking about some private
LoST deployments inside the NENA network where some other mechanisms and
architectures apply?

Best,
Karl

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 22 Jul 2013 15:02:24 +0000

I want to have LoST discovery find a local LoST server, which nearly always has the answer you want.  No FG, no real resolvers.

If the local LoST server doesn't have the answer, then we get to the forest.  If your local LoST server doesn't have the answer, it's next most likely that you need some adjacent server.  So walk up the tree a level and find it.

If something is broken, like the seeker for some reason isn't actually local, then you might need to go all the way up to the root of the tree, and across (using the FG), and down another tree.  This should be really rare, but it can happen.

Each server in the tree knows the leaves below (coverage and URI) so it can recurse or iterate down, and it knows the URI of the next level up so it can recurse or iterate up the tree.  That has to work, or the FG would have a zillion one level trees.  It doesn't, so the trees have intermediate servers that know about the leaves at their level, and can recure/iterate up.

I don't want to see devices start at the FG always.  That would mean that the FG is in the path of every emergency call (ignoring caching, which obviously helps a lot).  That's not a good design.  Stay local, and use the forest only when you have to go out of area for some reason.

Brian

On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:

Brian,

I got a bit confused here and I probably missed the discussion on the issue. However, the mapping architecture in RFC 5582 describes that a seeker queries a resolver, the resolver consults a forest guide and then goes to the root of the appropriate tree. So I don’t see how the RFC5582 architecture should work without the forest guide URI to be known by resolvers. Moreover, since the forest guide points to the root of the tree, the query has to start at the root. Or are you talking about some private LoST deployments inside the NENA network where some other mechanisms and architectures apply?

Best,
Karl

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Karl Heinz Wolf <[email-masked]>
Date: Tue, 23 Jul 2013 09:04:14 +0200

On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <[email-masked]>wrote:

>  I want to have LoST discovery find a local LoST server, which nearly
> always has the answer you want.  No FG, no real resolvers.
>

Brian, thanks for your answer. So this local LoST server would then be a
LoST mapping server for a specific reagion and a particular service (e.g.
urn:service:sos), do I understand this correctly? Then the client would
have to discover a real LoST resolver as well which it has to consult for
other services.

 If the local LoST server doesn't have the answer, then we get to the
> forest.  If your local LoST server doesn't have the answer, it's next most
> likely that you need some adjacent server.  So walk up the tree a level and
> find it.
>
>  If something is broken, like the seeker for some reason isn't actually
> local, then you might need to go all the way up to the root of the tree,
> and across (using the FG), and down another tree.  This should be really
> rare, but it can happen.
>
>  Each server in the tree knows the leaves below (coverage and URI) so it
> can recurse or iterate down, and it knows the URI of the next level up so
> it can recurse or iterate up the tree.  That has to work, or the FG would
> have a zillion one level trees.  It doesn't, so the trees have intermediate
> servers that know about the leaves at their level, and can recure/iterate
> up.
>
>  I don't want to see devices start at the FG always.  That would mean
> that the FG is in the path of every emergency call (ignoring caching, which
> obviously helps a lot).  That's not a good design.  Stay local, and use the
> forest only when you have to go out of area for some reason.
>

Does this mean the architecture of RFC 5582 is going to be updaded? After
all, this architecture is along the lines of the DNS system, where queries
would also always start at the DNS root servers when ignoring caching.

Best,
Karl

>
>
>  On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf <[email-masked]> wrote:
>
> [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 23 Jul 2013 12:45:34 +0000

If the local server didn't have the answer it could recur or iterate up the tree.  The client would never have to discover a resolver, the local server becomes one.

Brian

On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:
I want to have LoST discovery find a local LoST server, which nearly always has the answer you want.  No FG, no real resolvers.

Brian, thanks for your answer. So this local LoST server would then be a LoST mapping server for a specific reagion and a particular service (e.g. urn:service:sos), do I understand this correctly? Then the client would have to discover a real LoST resolver as well which it has to consult for other services.

Does this mean the architecture of RFC 5582 is going to be updaded? After all, this architecture is along the lines of the DNS system, where queries would also always start at the DNS root servers when ignoring caching.

Best,
Karl

Brian,

Best,
Karl

---

From: Karl Heinz Wolf <[email-masked]>
Date: Wed, 24 Jul 2013 08:46:47 +0200

On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian <[email-masked]>wrote:

>
>  If the local server didn't have the answer it could recur or iterate up
> the tree.  The client would never have to discover a resolver, the local
> server becomes one.
>

Brian,

so you suggest that all queries go to a local LoST server, consequently the
urn:service:sos tree would be bothered for each query, also for
urn:service:foo, which iterates up the urn:service:sos tree, until reaching
the forest guide that is able to tell the tree for service foo?

When you say that the local lost server becomes a resolver, I wonder what
ist the advantage of discovering a local LoST server? A resolver will verly
likely have the responses of all the "local" services in its cache
(urn:service:sos as well as any other), and all the other queries can be
directed to the right tree via forest guides, without bothering the
urn:service:sos tree at all.

Best,
Karl

>  On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf <[email-masked]> wrote:
>
>  Does this mean the architecture of RFC 5582 is going to be updaded?
> After all, this architecture is along the lines of the DNS system, where
> queries would also always start at the DNS root servers when ignoring
> caching.
>
>  Best,
> Karl
>
>
>
>>
>>
>>     On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <
>> [email-masked]> wrote:
>>
>>>

---

From: James Winterbottom <[email-masked]>
Date: Wed, 24 Jul 2013 18:22:09 +1000

My problem with this approach is that discovery mechanisms are domain name driven and this kind of means that local is domain local and not necessarily physically local so I am unclear on how to configure my network to make what is being proposed happen.

Cheers
James

Sent from my iPad

On 24/07/2013, at 4:46 PM, Karl Heinz Wolf <[email-masked]> wrote:

> On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian <[email-masked]> wrote:
>> 
> so you suggest that all queries go to a local LoST server, consequently the urn:service:sos tree would be bothered for each query, also for urn:service:foo, which iterates up the urn:service:sos tree, until reaching the forest guide that is able to tell the tree for service foo? 
> 
> When you say that the local lost server becomes a resolver, I wonder what ist the advantage of discovering a local LoST server? A resolver will verly likely have the responses of all the "local" services in its cache (urn:service:sos as well as any other), and all the other queries can be directed to the right tree via forest guides, without bothering the urn:service:sos tree at all. 
> 
> Best,
> Karl 
> 
>> 
>>> On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <[email-masked]> wrote:
>>>>> On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <[email-masked]> wrote:
>>>>>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 24 Jul 2013 13:25:43 +0000

If there is a service for urn:service:foo, the local LoST server knows how to serve it, or knows how to refer to some entity that can get it.
You can't iterate up the urn:service:sos tree looking for urn:service:foo.

The alternatives to searching bottom up is that the FG has to be expensive, like the DNS root - very widely replicated and dispersed.  I don't think that is deployable.  If the FG is only used when you need to cross trees (a query out of area), it's much less costly, much more deployable.  This also applies to intermediate LoST servers.  If the path is top down, all the intermediate servers need to be public.

I want the FG to be able to refuse queries that are from entities it does not know (it knows the leaves in the tree below it and the FGs it peers with).  That is much, much more deployable.

The FG can't be a public resource in my opinion.  We don't have organizations who would be willing to deploy those kinds of services for free like we did for DNS.

A public resource as attractive as an FG (or intermediate servers) that served urn:service:sos would need to withstand the largest DDoS attacks possible.  That is currently 300+ G and heading towards a terabit of attack traffic.  If it's not public, it doesn't need that level of threat mitigation.

The lowest level (the authoritative server) must be publicly accessible.  No way to avoid that I think.  I'm trying to figure out a way to get the FG deployed without that level of expense.  The lowest level is somewhat less attractive of a target than an FG would be, but it still would need to have very significant DDoS mitigation.

Brian

On Jul 24, 2013, at 2:46 AM, Karl Heinz Wolf <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:

Brian,

Best,
Karl

Best,
Karl

Brian,

Best,
Karl

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 24 Jul 2013 13:27:31 +0000

Your access network is physically local and your access network gives you DHCP.  Use DHCP LoST discovery on the access network and you get your local server.

Brian

On Jul 24, 2013, at 4:22 AM, James Winterbottom <[email-masked]<mailto:[email-masked]>> wrote:

Cheers
James

Sent from my iPad

On 24/07/2013, at 4:46 PM, Karl Heinz Wolf <[email-masked]<mailto:[email-masked]>> wrote:

Brian,

Best,
Karl

Best,
Karl

Brian,

Best,
Karl

---

From: Karl Heinz Wolf <[email-masked]>
Date: Thu, 25 Jul 2013 12:47:45 +0200

On Wed, Jul 24, 2013 at 3:25 PM, Rosen, Brian <[email-masked]>wrote:

>  If there is a service for urn:service:foo, the local LoST server knows
> how to serve it, or knows how to refer to some entity that can get it.
>

Sounds to me that the local LoST server would then actually be a mapping
server + forest guide. Who should actually operate the local LoST server?
Would the operator of the local urn:service:sos mapping server of a county
really want to peer with all other service operators like urn:service:foo
to exchange mappings via LoST sync so that the local LoST server is able to
know how to serve them, as you mentioned? Anyway, this seems like lots of
peering agreements.

Best,
Karl

>  The alternatives to searching bottom up is that the FG has to be
> expensive, like the DNS root - very widely replicated and dispersed.  I
> don't think that is deployable.  If the FG is only used when you need to
> cross trees (a query out of area), it's much less costly, much
>
more deployable.  This also applies to intermediate LoST servers.  If the
> path is top down, all the intermediate servers need to be public.
>
>  I want the FG to be able to refuse queries that are from entities it
> does not know (it knows the leaves in the tree below it and the FGs it
> peers with).  That is much, much more deployable.
>
>  The FG can't be a public resource in my opinion.  We don't have
> organizations who would be willing to deploy those kinds of services for
> free like we did for DNS.
>
>  A public resource as attractive as an FG (or intermediate servers) that
> served urn:service:sos would need to withstand the largest DDoS attacks
> possible.  That is currently 300+ G and heading towards a terabit of attack
> traffic.  If it's not public, it doesn't need that level of threat
> mitigation.
>
>  The lowest level (the authoritative server) must be publicly accessible.
>  No way to avoid that I think.  I'm trying to figure out a way to get the
> FG deployed without that level of expense.  The lowest level is somewhat
> less attractive of a target than an FG would be, but it still would need to
> have very significant DDoS mitigation.
>
>  Brian
>
>
>  On Jul 24, 2013, at 2:46 AM, Karl Heinz Wolf <[email-masked]> wrote:
>
>  so you suggest that all queries go to a local LoST server, consequently
> the urn:service:sos tree would be bothered for each query, also for
>  When you say that the local lost server becomes a resolver, I wonder
> what ist the advantage of discovering a local LoST server? A resolver will
> verly likely have the responses of all the "local" services in its cache
>>  Brian, thanks for your answer. So this local LoST server would then be
>> a LoST mapping server for a specific reagion and a particular service (e.g.
>>>  Each server in the tree knows the leaves below (coverage and URI) so
>>> it can recurse or iterate down, and it knows the URI of the next level up
>>> so it can recurse or iterate up the tree.  That has to work, or the FG
>>> would have a zillion one level trees.  It doesn't, so the trees have
>>> intermediate servers that know about the leaves at their level, and can
>>> recure/iterate up.
>>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 25 Jul 2013 13:55:13 +0000

No, it's just a LoST server that knows about trees its in.  Nothing more, nothing less.

It might be run by the access network or, in the case of urn:service:sos, the local emergency authorities.

It's just in a tree (or perhaps more than one tree if it serves multiple "top level" services).  It doesn't know about forest guides unless it is at the top of the tree (which might be common for some places with urn:service:sos where the "tree" is one level, one server).

If it doesn't know a mapping, if refers/recurs up the tree.  If it's at the top of the tree (a root server), it uses mappings it obtains from a FG to refer/recur to another tree.

Unless it's at the top of the tree, it's only sending its service boundary and URI to its parent.  That's not LoST sync really because it's only one way.  It refers anything it isn't authoritative for to its parent, but doesn't have any coverage info from the parent.  It doesn't need any.

Brian

On Jul 25, 2013, at 6:47 AM, Karl Heinz Wolf <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jul 24, 2013 at 3:25 PM, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:
If there is a service for urn:service:foo, the local LoST server knows how to serve it, or knows how to refer to some entity that can get it.

Sounds to me that the local LoST server would then actually be a mapping server + forest guide. Who should actually operate the local LoST server? Would the operator of the local urn:service:sos mapping server of a county really want to peer with all other service operators like urn:service:foo to exchange mappings via LoST sync so that the local LoST server is able to know how to serve them, as you mentioned? Anyway, this seems like lots of peering agreements.

Best,
Karl

The alternatives to searching bottom up is that the FG has to be expensive, like the DNS root - very widely replicated and dispersed.  I don't think that is deployable.  If the FG is only used when you need to cross trees (a query out of area), it's much less costly, much
more deployable.  This also applies to intermediate LoST servers.  If the path is top down, all the intermediate servers need to be public.

Brian

Brian,

Best,
Karl

Best,
Karl

Brian,

Best,
Karl

---

From: Karl Heinz Wolf <[email-masked]>
Date: Wed, 31 Jul 2013 09:23:57 +0200

On Thu, Jul 25, 2013 at 3:55 PM, Rosen, Brian <[email-masked]>wrote:

>  It might be run by the access network or, in the case of
> urn:service:sos, the local emergency authorities.
>
>  It's just in a tree (or perhaps more than one tree if it serves multiple
> "top level" services).  It doesn't know about forest guides unless it is at
> the top of the tree (which might be common for some places with
> urn:service:sos where the "tree" is one level, one server).
>
>  If it doesn't know a mapping, if refers/recurs up the tree.  If it's at
> the top of the tree (a root server), it uses mappings it obtains from a FG
> to refer/recur to another tree.
>

Brian, seems that the architecture you are talking about is somehow
differnet from RFC 5582, so could you please point me to the document
describing your architecture so that I can follow up better? Thank you.

> Unless it's at the top of the tree, it's only sending its service boundary
> and URI to its parent.  That's not LoST sync really because it's only one
> way.  It refers anything it isn't authoritative for to its parent, but
> doesn't have any coverage info from the parent.  It doesn't need any.
>

LoST sync can also be used to push coverage reagions up a tree.

karl

>
>  Brian
>
>   On Jul 25, 2013, at 6:47 AM, Karl Heinz Wolf <[email-masked]> wrote:
>
>   more deployable.  This also applies to intermediate LoST servers.  If
>> the path is top down, all the intermediate servers need to be public.
>>
>>  The lowest level (the authoritative server) must be publicly
>> accessible.  No way to avoid that I think.  I'm trying to figure out a way
>> to get the FG deployed without that level of expense.  The lowest level is
>> somewhat less attractive of a target than an FG would be, but it still
>> would need to have very significant DDoS mitigation.
>>
>>  Brian
>>
>>
>>>   On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <[email-masked]
>>> > wrote:
>>>
>>>>  If something is broken, like the seeker for some reason isn't
>>>> actually local, then you might need to go all the way up to the root of the
>>>> tree, and across (using the FG), and down another tree.  This should be
>>>> really rare, but it can happen.
>>>>