Subject: Re: [Anima-signaling] [Anima-bootstrap] Bootstrap discovery question

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Nov 2015 11:14:07 -0800

[cc'ing signaling team ? (hopefully this is ok. to keep everybody in sync]

Forget about bootstrap, but in general:

IMHO, URL/URI is the most important locator. When someone looks for a service/objective,
it ultimately needs to get everything to build a protocol connection to achieve this
objective/connect-to-this-service. Which means so much more than just IP* adress, but also
transport protocol, port, higher layer protocols, etc. pp.

Why the heck would we want to have to reinvent messaging elements to reinvent
signaling all those connection attributes if there is already one solution for this:
URI.

Example, bootstrap: The bootstrap proxy agent needs to discover the "an-registrar-enrollment"
service (i just made up that name, somebody had to do it ;-). In return i think you
would get back (according to RFC7030, 3.2.2):

https://<ipv6addr-of-registrar>{:<port>}/.well-known/est

Of course we could support multiple enrollment protocols, but every proxy that does
support rfc7030 would recognize this as a URI indicating RFC7030. This is because of
/.well-known/est. And it then knows the necessary transport protocol pieces: IPv6
addr and port and use of HTTPS. As a rule of thumb for services where the locator is
in the ACP, we would require IPv6 address so that we do not introduce the need for
ACP-wide DNS host-name lookup and registration.

If there is a way to reuse more/better our existing IETF toolset, please chime in.

Cheers
    Toerless

On Thu, Nov 26, 2015 at 07:53:42AM +1300, Brian E Carpenter wrote:
> Here's a hopefully simple question from the GRASP side of the house.
> 
> If the bootstrap uses GRASP discovery, what sort of locator will
> it be trying to discover?
> 
> At the moment GRASP has four locator types in the design:
> 
> - IPv6 address
> - IPv4 address
> - FQDN
> - URL
> 
> It's been suggested by a reviewer that the URL option is unnecessary.
> 
> Regards
>    Brian
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

-- 
---
Toerless Eckert, [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Nov 2015 08:30:07 +1300

OK, I've cc'ed Joel as well since it was his review that triggered my question.

Agreed, if we want GRASP discovery to be capable of serving as a general-purpose
discovery tool, we don't really need to justify the FQDN or URI/URL options.
Joel's point was essentially the same as what you say below ("where the locator
is in the ACP, we would require IPv6 address so that we do not introduce the need
for ACP-wide DNS host-name lookup and registration"). So the FQDN and URI/URL
options are not for "normal" GRASP operation.

     Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Nov 2015 15:02:20 -0500

Yes, the key for me is what these "locators" are for.  If they are for 
Anima Applications, that makes sense.  I can believe that there 
applications for which a URL is a good location.  If they are for the 
bootstrap process itself, that seems problematic.

I will also note in passing that trying to use a URL as a way of 
bundling several related but separate pieces of information seems 
problematic.  Even burying the IP address and port number in the URL 
domain portion does not seem to be a good idea unless that same URL is 
what is to be used to send the resulting messages (for example if the 
service were on top of SOAP).

Yours,
Joel

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Nov 2015 12:05:56 -0800

> discovery tool, we don't really need to justify the FQDN or URI/URL options.

RIght.

> for ACP-wide DNS host-name lookup and registration"). 

Yes, but as i outlined above, the IPv6 address alone is not sufficient because we
also need other locator pieces (port, L4-protocoll security protocols, etc. pp). And
all of that is in the URL.

In fact, i was arguing that IP* address or FQDN are unnecessary as explicit locator
objects. Just as in a browser: you enter www.foobar.com or 10.0.0.1, but its just an
abbreviation for http://www.foobar.com or http://10.0.0.1. But abbreviations make
only sense for human interfaces or if you're really in desparate need of saving bytes. I
hope neither applies to GARP. If we really want abbreviations, we should really
define it that way:

locator field contains a URL or abbreviated URL. An abbreviated URL is only
permissible if for the service requested there is a clear specification what
the default parameters are that can be abbreviated away.

> So the FQDN and URI/URL > options are not for "normal" GRASP operation.

?? Not clear .

The other point i made was that we should mandate use of IPv6 addresses in the URL
as long as it points to an objective in the ACP. Did you mean to refer to that piece ?

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Nov 2015 12:17:11 -0800

> bootstrap process itself, that seems problematic.

What is bad about rfc7030 ? https://<registrars-ipv6>//.wellknown/est

How else would you want to indicate that you can support bootstrap via RFC7030 ?
Thats how it's defined. Only important details is not to use an FQDN for the
IP address of the URL.

> problematic.

Whot ??? Why the heck do we have URLs ? The pieces in a URL are not several,
unrelated pieces of information. The idea is to have URLs describing the minimum
necessary pieces of information to actually locate a service.

> Even burying the IP address and port number in the URL 

The EST connection would be established to the IPv6 address in the URL, right.

There is no need for hostname DNS in ACP. Hostnames are just an optimization
for services provided by only one host. I haven't seen a requirement to make
ACP ervice discovery depend on having this redundant layer.

Btw: The rfc7030 trust model for https:// between client and registrar in the ACP is
NOT based on the client believing registrar.domain is valid because of some bogus
CA signed cert for "registrar.domain", but because of

a) The connection runs across an end-to-end trusted/encrypted transport (ACP).
b) The IPv6 address of the registrar and the client are derived from their certificates.
   Aka: This is similar to the "registrar.domain" trust, only that its mutual
   and not dependent on random CAs, but both registrar and client cert are from the
   same CA.

Cheers
    Toerless

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Nov 2015 15:20:46 -0500

There are two issues for me.

First, as far as I can tell, 7030 actually runs over HTTP.  As such, it 
makes good sense to use URLs.  ACP and GRASP do not run over HTTP.

Second, the document does not say that we use 7030 well known URLs.  It 
says that you can use any old URL.  I can believe that with suitable 
restrictions, there are URLs that can be used.  But the document does 
not place any such restrictions.

yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Nov 2015 10:12:15 +1300

On 26/11/2015 09:20, Joel M. Halpern wrote:
> First, as far as I can tell, 7030 actually runs over HTTP.  As such, it makes good sense to use URLs.  ACP and GRASP do not run
> over HTTP.
> 
> Second, the document does not say that we use 7030 well known URLs.  It says that you can use any old URL.  I can believe that
> with suitable restrictions, there are URLs that can be used.  But the document does not place any such restrictions.

I think that's reasonable, because GRASP (discovery) is just a carrier
for this information.

But I definitely disagree with Toerless that it would be reasonable to
use a URI format for the purpose of carrying an (ACP) IP address. It's
a very inefficient way to carry a 128 bit quantity that in the GRASP
context is only needed for socket calls, so it never needs to be parsed
or presented to a human.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Nov 2015 13:18:59 -0800

On Wed, Nov 25, 2015 at 03:20:46PM -0500, Joel M. Halpern wrote:
> makes good sense to use URLs.

https actually.

> ACP and GRASP do not run over HTTP.

Right. 

But my argument for URLs was not meant to be limited to services on top of
http(s), but generic. URLs are the IETFs way to locate resources. IMHO
an objective/service is well characterised as being a subset of resources.

> not place any such restrictions.

Sure, we can look into refining the wording.

Also, my answer wasn't meant to be conclusive, just to say that URL is
better/more important than IP* address or FQDN.

My open AI is this: Whenever GRASP tries to find a service for which
parameters are needed, we should tr try to avoid reinventing the wheel
how to define / register those attributes. FOr some services/parameters,
URLs do a great job for this, eg: port-number for many TCP/UDP services
with URLs defined. For other services, DNS-SD does a pretty good job
via the parameteres of the SRV and TXT records. So i would like to see
how much of this we could reuse in GRASP. 

For example, DNS-SD permits to encode a lot of parameters as
<param>=<value> concatenated via ";" into TXT record. Lets assume some
GRASP objective/service needs to indicate such parameters. How should we
encode them when using GRASP ? 

Have in GRASP also such a "parameter" element ? Break up the TXT
into individual JSON/CBOR string/value attributes ? Append them to the URL...

Cheers
    toerless

> >>>>objective/connect-to-this-service. Which means so much more than just 
> >>>>IP*
> >>>>adress, but also
> >>>>service (i just made up that name, somebody had to do it ;-). In return 
> >>>>i
> >>>>think you
> >>>>Of course we could support multiple enrollment protocols, but every 
> >>>>proxy
> >>>>that does
> >>>>support rfc7030 would recognize this as a URI indicating RFC7030. This 
> >>>>is
> >>>>because of
> >>>>addr and port and use of HTTPS. As a rule of thumb for services where 
> >>>>the
> >>>>locator is
> >>>>in the ACP, we would require IPv6 address so that we do not introduce 
> >>>>the
> >>>>need for

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Nov 2015 13:52:57 -0800

> context is only needed for socket calls, so it never needs to be parsed

DNS-SD has string based <param-name>=<param-value> attributes. These
are carried together in a single mDNS packet if mDNS is used. AFAIK,
nobody ever argued that those have to generically be encoded more compact,
but of course everybody is aware of the UDP/mDNS packet size limitation
and makes ssure the total information does not exceed eg: 1280.

Aka: My rule of thumb would be to always have a tight eye on fitting
GRASP service announcements within 1280 everything included. As long as
we feel safe on that, do as little additional optimization of pre-defined
data as necessary. 

If necessary, just have a CBOR binary <A>ddress attribute and then define
a URL template to use in GRASP:

  scheme://%A/....  -> %A : Name resolves to address in <A> element

Btw: I think we do need to have the DNS-SD parameters as well so that
we wouldn't have to reinvent the wheel for services that are well defined
via DNS-SD definitions ;-))

Cheers
    Toerless

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Nov 2015 18:00:34 -0500

I think the problem is much simpler Toerless.
You want to be able to use a specific format of URL in certain 
circumstances.  That particular usage seems defensible.

But if we want to do that, we need to make very clear that only that 
usage is allowed.  Shipping arbitrary URLs around and expecting them to 
do the right thing seems at best over-optimistic.

I agree that we should not invent new ways of packaging information.
I am not at all sure I agree that a URL is the IETF agreed way for 
packaging information at any layer other than the application layer.

Yours,
Joel

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Nov 2015 15:40:35 -0800

So, with that said: What's your suggestion to best define in an extensible
fashion the locators for services/objectives with minimum new definitions and
maximum reuse of known/working IETF solutions. To me the known/working IETF
solutions are URLs and DNS-SD. 

I do agree that so far a lot of stuff below the app-layer in the IETF has
created as many new registries for assigned name & numbers as threy could
(ok, maybe a bit cynical). I really wish we could come up with a framework 
for anima that doesn't require contiguously new registries when new agents are
written.

Cheers
    Toerless

On Wed, Nov 25, 2015 at 06:00:34PM -0500, Joel M. Halpern wrote:
> >>>>>>Joel's point was essentially the same as what you say below ("where 
> >>>>>>the
> >>>>>>locator
> >>>>>>is in the ACP, we would require IPv6 address so that we do not 
> >>>>>>introduce
> >>>>>>the need
> >>>>>>>it ultimately needs to get everything to build a protocol connection 
> >>>>>>>to
> >>>>>>>achieve this
> >>>>>>>objective/connect-to-this-service. Which means so much more than 
> >>>>>>>just IP*
> >>>>>>>adress, but also
> >>>>>>>service (i just made up that name, somebody had to do it ;-). In 
> >>>>>>>return i
> >>>>>>>think you
> >>>>>>>support rfc7030 would recognize this as a URI indicating RFC7030. 
> >>>>>>>This is
> >>>>>>>because of
> >>>>>>>addr and port and use of HTTPS. As a rule of thumb for services 
> >>>>>>>where the
> >>>>>>>locator is
> >>>>>>>in the ACP, we would require IPv6 address so that we do not 
> >>>>>>>introduce the
> >>>>>>>need for
> >>>>>>>If there is a way to reuse more/better our existing IETF toolset, 
> >>>>>>>please
> >>>>>>>chime in.
> >>>>>>>
> >>>>>>>Cheers
> >>>>>>>      Toerless
> >>>>>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Nov 2015 13:32:11 +1300

> solutions are URLs and DNS-SD.

I begin to suspect that you are using "locator" to mean more than I do.
To me, a locator contains no semantics whatever. "<param-name>=<param-value>
attributes" is not part of a locator.

The value field of a GRASP objective is defined as "a single value or a data
structure of any kind." So there's no problem if you want to embed whatever
you want, such as <param-name>=<param-value> attributes. However, GRASP
discovery is only aimed at discovering the locator of an ASA that supports a
given objective, with the option of following up by synchronizing or negotiating
the value. (And with Bing's favourite optimization, rapid mode discovery,
you can discover a peer and fetch the value in one operation.)

Again, there is nothing in GRASP that prevents using DNS-SD or URI formats,
or HTML, XML, YANG or anything else you want, once you have found the
locator of your peer. Equally, you can use pure binary if you like.

(I agree that message sizes SHOULD be small, but they MAY be large.)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Nov 2015 13:46:51 +1300

Oops, missed this:

> I really wish we could come up with a framework 

Well, we've made it as simple as we can while preserving uniqueness:

For generic objective names: Specification Required policy.
For "vendor"-defined objective names: tagged with PEN or domain name (TBD).

So, no new registry for proprietary or local ASAs. Hopefully we would
end up with a small library of generic ones.

Regards
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Nov 2015 16:52:33 -0800

> attributes" is not part of a locator.

Yes, good question how to most precisely define locator.

IMHO the IP address, protocol (eg: UDP vs. TCP, HTTPs vs. HTTP) are part
of locating the service. DNS-SD parameters may be that if they indicate
such non-negotiable parts of establishing the connection. But they might
also be something maybe better called "selector". 

> you can discover a peer and fetch the value in one operation.)

Well, lets understand the workflow needed to select one service/objective
instance from multiple:

Lets say GRASP client is asking for tghe objective, eg: bootstrap,
and it gets three replies:

   -> reply 1 is for a protocol choice incompatible with the client.
   -> reply 2 is for a client supported protocol, but some inferior parameters
   -> reply 3 is for a client supported protocols, with better parameters

In general, you want to be able to provide the necessary information
(protocol/parameters) as part of the service/objective discovery, so
that the client can immediately pick the best compatible one.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Nov 2015 14:24:58 +1300

> that the client can immediately pick the best compatible one.

Yes. With GRASP as currently designed you would do that by executing
discover/synch for an objective called, say "trust_relay" and the
objective values returned would be [protocol_name, *parameter_value].
This is a case where the GRASP client wants all the replies, not
just the first one.

    Brian