Subject: [Anima-bootstrap] anima-bootstrap: Bootstrap proxy discovery options

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Dec 2015 17:43:33 -0800

As promised during call: 

Proposed Discovery phase for AN-Bootstrap:

1. Mandatory: Discovery of bootstrap-proxy link-local

   I think this should be via GRASP, but GRASP may not want to provide what i think is
   best, so let me maybe first describe what i think is best, independent
   of what protocol we use and solicit feedback on it and then we can discuss
   with GRAP if/how to fit it there:

   IMHO, i would let the proxy periodically (30 secs) just announce that its providing
   AN enrollment proxy function via link-local IPv6 multicast. Maybe with port-number
   and protocol (EST over IPv6 link-local ) as parameters so it's extensible.

   Why ?

   I don't want to make the proxy more attackable than it needs to be. Anything
   that it needs to respond to is something it can be attacked with. Unsolicited
   periodic link-local multicast that do not need/want any response are really hard to attack.

   I don't want the enrolling device to be more attackable than necessarily.
   Arguably such a greenfield device may be more attackable than a configured
   device. An unconfigured device that periodically broadcasts "hey, i am unconfigured
   and look for a proxy server" (especially when powered on in a non-AN enviroment)
   is the best victim ever to do a port-scan etc. pp.  on (or just find the console
   interface). And just because a vendor has added autonomic networking doesn't mean
   he has now also fixed all security for all OS services many of which may not even be
   off by default but would likely be configured off by security sensitive operators. 

   Sure, could an attacker find a greenfield device by also broadcasting the
   link-local "i am an AN-proxy" messages ? But now you have an active attacker.
   And for example, we could include in the periodic announcements a timestamp
   signed with the proxies domain certificate. Thats something the attacker
   can not fake. The greenfield device may not be able to figure out
   whose link-local multicast to trust, but the real an-proxy can listen to someone
   else multicasting itself as a proxy. And if thats not from another proxy in the
   same AN domain, then this could trigger an alert to ops (syslog or trap).
   And of course the greenfield device should not trust an L2 unicasted "i am proxy"
   message, because that might be a trick from an attacker to not be seen by a real proxy
   on the same (wired) LAN.
   
   So, i think we can use GARP DISCOVER for this periodic multicast, only that
   GARP DISCOVER really wants to see a GARP reply, but in our case we really
   just want the greenfield device to immediately connect to our EST TCP port,
   no need for any further chat before doing that. So thats where we'd need to have
   the discuss with GARP folks what they think. 

   Also comparison with mDNS as we discussed it:
     - code size: We need GRASP for more functions in AN beside discovery,
       we do not need mDNS for anything in AN, so on IoT devices we would save
       code size. TBD: Size of an mDNS stack (note: We MAY want "normal" DNS,
       so the code size for mDNS may not be that large as a delta on top of
       "normal" DNS).
     - Number of packet exchanges (TBD: not clear how much this is a real
       problem, mDNS may optimize here): mDNS exchange is logical three step:
       PTR RR lookup -> SRV, TXT RR lookup, AAAA lookup
     - mDNS being a query/reply exchange wouldn't have the security properties
       i described above. Unless you abuse it and engineer an MDNS unsolicited
       announce periodically with all the four RRs included. And i guess
       one could define a TXT RR with the signed timestamp. Aka: I could probably
       do the same thing i was describing above also with mDNS. Not sure if
       mDNS people would like that...

2. If 1. failed:  OPTIONAL Discovery of bootstrap proxy via L3

   Does not need to be supported on all AN devices, but only those that
   want to be able to auto-bootstrap when connected to some "IP-network/Internet"
   connection. Would also like comments from Kent because his draft/use-cases
   will likely have a lot of overlap/opinions here.

   a) Try to get (routed) IPv6/IPv4 address. IPv4 by DHCP, IPv6 SLAAC and/or DHCP.

   b) If address via DHCP request DHCP option holding AN bootstrap parameter
      TBD: Option 124/125. Maybe Ralph Droms can quickly point to best practices
      from IETF standards perspective, else i need to dig more for what i've seen
      as best practices.

   c) If DHCP successfull, DHCP reply will provide IP/IPv6 address or domain-name
      of bootstrap proxy. Connect to it.

      This case will allow you to connect to a proxy in the customer network
      (aka: network that generates the DHCP reply). This option will not work
      when connecting to the Internet.

   d) If using SLAAC (IPv6): TBD. Need to ask IPv6 experts if IPv6 RA etc. 
      can usefully provide add-on info like DHCP can (don't think so).

   e) If DHCP and/or SLAAC fail to find bootstrap proxy, use DNS:

   f) DHCP/SLAAC should have provided local <domain>.
      Look up autonomic-bootstrap-proxy.<domain> A/AAAA addresses (depending
      on whether device has IPv4 and/or IPv6 address from a). Connect to
      that IPv4/IPv6 address of bootstrap server.

   g) OPTIONAL:
      If f) has failed, create domain-name <name>.<vendor>.

      This connects to proxy in the internet operated by device vendor,
      which is the only option when connecting directly to the Internet,
      where no DHCP option is possible (from owner) and where you do not
      get a useful DNS prefix (but just DNS prefix from SP).

      Of course this only needs to be implemented if vendor is happy to 
      operate (or outsource) such a proxy on the Internet. So it's even more optional
      then the whole L3 bootstrap option overall.
   
Removed: I am somewhat a fan of link-local IPv4 (they're cute), but i really
don't see a reason for them: The proxy also needs to support AN functions anyhow,
so it will always be able to do IPv6.

   a)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Dec 2015 17:27:37 +1300

On 04/12/2015 14:43, Toerless Eckert wrote:

...
>    AN enrollment proxy function via link-local IPv6 multicast. 

Here's the Python code to do that with my prototype:

import grasp
import time

OK, nonce = grasp.register_asa("Boot")
if not OK:
    #we've got a serious problem...
    raise RuntimeError("Can't register as ASA")

obj = objective(0,":Boot")
x = grasp.register_obj(nonce, obj)
if not x == "OK":
    #we've got a different problem...
    raise RuntimeError(x)

while True:
    grasp.discover(nonce, obj, 30000)

What this does is register the caller as an ASA called "Boot" that handles the
objective called ":Boot", and then LL multicast a discovery message every
30s. That will tell the others that it's there. It's running in another window
as I type. I didn't write the handler code for the receiving end yet though,
so I just get output like this twice a minute:

CBOR->Python gives:  [1, 1248700, b'$\x06\xe0\x07S\x07\x00\x01(\xcc\xdcL\x97\x03g\x81', ':Boot', 0, 6, 0]

> Maybe with port-number

If you want parameters, we'd need to use the (synch) flooding method
instead. Maybe I'll write that code next week; it will be very similar to
the discovery case. I don't think there are any real problems here.

Python+CBOR is fun. Thanks, Toerless, for pushing the CBOR idea.

   Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 4 Dec 2015 23:44:53 +0000

Brian, 

Are the session-id and the nonce equivalent?

Why is the 30000 a parameter passed into the into the grasp.discover call? This looks like a timeout for how long to wait for a response (GRASP_DEF_TIMEOUT/2)? If so this would provide the 30s behavior but is leveraging a side-effect dubiously. Sufficient for PoC; I’m just asking to understand. 

Toerless’s suggestion appears to be to include the “locator-option” within the discover message. Did you include that? Currently "locator-option” is not part of the [grasp] s3.7.2 Discover Message. Are you comfortable adding that as Toerless argues for?

- max

> On Dec 3, 2015, at 9:27 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Dec 2015 13:06:36 +1300

> Are the session-id and the nonce equivalent?

Well, I made an implementation choice that when an ASA registers itself
with GRASP it gets back a nonce, used to validate future calls, so
that no other process can masquerade as the same ASA. And yes, I
just re-used the existing Session ID mechanism to assign that nonce.
However, each transaction that an ASA initiates will get its own
Session ID.

> Why is the 30000 a parameter passed into the into the grasp.discover call? This looks like a timeout for how long to wait for a response (GRASP_DEF_TIMEOUT/2)? If so this would provide the 30s beha…

Correct. Again, it's just an implementation choice and I agree it's a bit
of a kludge. It could be done more elegantly. (Although I must say that the
threading support in Python is a dream to use.)

> Toerless’s suggestion appears to be to include the “locator-option” within the discover message. Did you include that? Currently "locator-option” is not part of the [grasp] s3.7.2 Discover Message.…

It turns out that we have to do that anyway, for other reasons that Joel Halpern
pointed out (since Session IDs are unique per node, not network-wide). That will
be fixed in the next GRASP draft. But in any case, the recipient of a LL multicast
can know the source address (and interface #) even if they are not in the payload.
So this isn't a problem.

However, I do think that the "announcement" nature of this is better suited
to the unsolicited flooding message than the Discovery message, because then
it's natural to include data in the message.

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Sat, 5 Dec 2015 00:18:39 +0000

Toerless, I suggest breaking this thread into two. I’m only responding to the first half of your msg below,

> On Dec 3, 2015, at 6:43 PM, Toerless Eckert (eckert) <[email-masked]> wrote:
> 
> As promised during call: 
> 
>   IMHO, i would let the proxy periodically (30 secs)

Is it acceptable that a new device sits for 30s before joining? Should this be shorter? Longer? What criteria do we use to choose (see below before answering). 

> just announce that its providing

This is a solid argument in favor of casting the AN new device as the “responder” for the protocol exchange. 

> 
>   So, i think we can use GARP DISCOVER for this periodic multicast,

Multicast DNS supports multicast “unsolicited” responses and also specifically states that peers cache these. So the basic behavior you are requesting is fundamentally available from mDNS as well. This is a design choice for Anima but I doesn’t seem to dramatically impact our choice of discovery protocols.

I do note that mDNS s8.3 indicates that:
"  A Multicast DNS responder MUST NOT send announcements in the absence
   of information that its network connectivity may have changed in some
   relevant way.  In particular, a Multicast DNS responder MUST NOT send
   regular periodic announcements as a matter of course.”
It would be interesting to understand why they felt a need to prohibit the type of behavior you’re looking for. Perhaps their concerns here impact the choice of 30s arbitrarily made above. 

> only that

This is where the real value/difference discussion comes in. I guess we could build an avahi library and see how much the entire thing takes or how big pieces of it are. 

>       announce periodically with all the four RRs included.

As noted above this doesn’t look problematic. The real issue is that they found it important to prohibit this type of behavior and we should understand why before adopting your proposed initiator model. 

> And i guess
>       mDNS people would like that…

For a DNS based solution I guess DNSsec integration would be logical. I’m not sure I like any approach where we try to cram security into the discovery protocol — the truth is that we don’t have sufficient information to trust crypto methods in the response/broadcast information until after we complete bootstrapping at which point its relatively moot. Instead we can cut to the heart of your security value by tracking "locator-option” information seen and freaking out if an unexpected one was seen (assuming GRASP). 

More broadly: 

In return I worry about forcing GRASP to be used for any bootstrapping. Yes, I recognize this is reasonable for Anima but its still a valid concern as doing so really ties bootstrapping to anima when it doesn’t need to be.

I’m also worried that GRASP implementations assume a secure transport later via ACP or TLS and don’t find the current language in s3.3.1 and s3.3.2 to be very clear about what happens when these are not used. I prefer an approach where we can clearly provide a bright line and state that “this exchange is not secure”. Running Grasp in both modes is unclear and confusing.

- max

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Sat, 5 Dec 2015 00:25:54 +0000

> On Dec 4, 2015, at 5:06 PM, Brian E Carpenter <[email-masked]> wrote:
> 

all goodness. thanks. 

> it's natural to include data in the message.

so rather than add “locator-option” to the discovery message use unsolicited response messages. This makes sense (very similar to mDNS approach!). 

FYI - as an editorial note the paragraph explaining flooding is buried in s3.3.5 and could probably be called out more clearly in the text. Perhaps its own section or in the Response section? Similarly s3.9.1 includes the text: "and for terminating flooding as described in FLOODING” which looks like an incomplete reference as if you had already planned to pull flooding out into its own section.

- max

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Dec 2015 13:42:22 +1300

> FYI - as an editorial note the paragraph explaining flooding is buried in s3.3.5 and could probably be called out more clearly in the text. Perhaps its own section or in the Response section? Simil…

Good points.

BTW I don't fundamentally care whether or not bootstrap uses the GRASP
mechanisms - I just want to make sure that they *could* be used if that
turns out to be optimal.

Regards
   Brian

---

From: peter van der Stok <[email-masked]>
Date: Mon, 07 Dec 2015 09:54:52 +0100

Hi Toerless,

A few remarks to your extensive e_mail

>        mDNS people would like that...

I checked mDNS-SD (it is not too complex),
It is sufficient to send a query for the SRV RR containing the required 
service.
(Knowing that your service must exist removes the need for checking its 
existence, so no PTR query).
mDNS should also return the AAAA RR defined by the contents of the SRV 
RR in the same message.
The DNS encoding of the messages is pretty concise. (for example, name 
strings occur only once)

> 2. If 1. failed:  OPTIONAL Discovery of bootstrap proxy via L3
Many installations will have their own brand of service discovery (SD).
Inter-operability of SD is the first objective; we can safely assume 
that if a given brand of SD is used,
the whole installation uses this brand as specified by a SDO that is 
active in this particular market.

I think it is sufficient to state that the proxy service needs to be 
discovered
and how this can be done with DNS-SD (mDNS) or DHCP, the IETF standards.

Greetings,

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 8 Dec 2015 08:05:00 +1300

On 07/12/2015 21:54, peter van der Stok wrote:
> It is sufficient to send a query for the SRV RR containing the required service.
> (Knowing that your service must exist removes the need for checking its existence, so no PTR query).
> mDNS should also return the AAAA RR defined by the contents of the SRV RR in the same message.
> The DNS encoding of the messages is pretty concise. (for example, name strings occur only once)
> 
>>
> Inter-operability of SD is the first objective; we can safely assume that if a given brand of SD is used,
> the whole installation uses this brand as specified by a SDO that is active in this particular market.
> 
> I think it is sufficient to state that the proxy service needs to be discovered

Just remember that in a truly autonomic network built with factory-reset
devices, we cannot assume that anything at all has been configured or
named.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Dec 2015 14:07:13 -0500

> Is it acceptable that a new device sits for 30s before joining? Should
    > this be shorter? Longer? What criteria do we use to choose (see below
    > before answering).

    >> I don't want the enrolling device to be more attackable than
    >> necessarily.  Arguably such a greenfield device may be more attackable
    >> than a configured device. An unconfigured device that periodically
    >> broadcasts "hey, i am unconfigured and look for a proxy server"
    >> (especially when powered on in a non-AN enviroment) is the best victim
    >> ever to do a port-scan etc. pp.  on (or just find the console
    >> interface). And just because a vendor has added autonomic networking
    >> doesn't mean he has now also fixed all security for all OS services
    >> many of which may not even be off by default but would likely be
    >> configured off by security sensitive operators.

This is one reason I'd like the new device to do things that configured
devices do regularly.
So sending out a multicast IKEv2 INIT might really make sense here.
Every device should do it every 5 to 15 minutes.

A new device will either send them, or receive them.  Either way, it can
respond and within the privacy of IKEv2, can do something.
That doesn't you can't use a proxy to get things through: the resulting
one-hop-ACP won't be part of the production ACP.

    > Multicast DNS supports multicast “unsolicited” responses and also
    > specifically states that peers cache these. So the basic behavior you
    > are requesting is fundamentally available from mDNS as well. This is a
    > design choice for Anima but I doesn’t seem to dramatically impact our
    > choice of discovery protocols.

mDNS is another good mechanism to use --- and it doesn't scream out, "newbie"
either.

    >> Also comparison with mDNS as we discussed it: - code size: We need
    >> GRASP for more functions in AN beside discovery, we do not need mDNS
    >> for anything in AN, so on IoT devices we would save code size. TBD:
    >> Size of an mDNS stack (note: We MAY want "normal" DNS, so the code
    >> size for mDNS may not be that large as a delta on top of "normal"
    >> DNS).

    > This is where the real value/difference discussion comes in. I guess we
    > could build an avahi library and see how much the entire thing takes or
    > how big pieces of it are.

I claim that much of what we are doing with the ACP and GRASP is outside the
code space limit for a constrained IoT device, so I don't buy this argument.

1) mDNS *IS* useful in IoT space, so the code isn't wasted.
2) GRASP is *not* useful in constrained IoT space.

    >> And i guess one could define a TXT RR with the signed timestamp. Aka:
    >> I could probably do the same thing i was describing above also with
    >> mDNS. Not sure if mDNS people would like that…

    > For a DNS based solution I guess DNSsec integration would be
    > logical. I’m not sure I like any approach where we try to cram security
    > into the discovery protocol — the truth is that we don’t have
    > sufficient information to trust crypto methods in the
    > response/broadcast information until after we complete bootstrapping at
    > which point its relatively moot. Instead we can cut to the heart of
    > your security value by tracking "locator-option” information seen and
    > freaking out if an unexpected one was seen (assuming GRASP).

Exactly: You can't easily do DNSSEC easily here: no trust anchors available for
         joining device.  DNSSEC can give you an alternative to 802.1AR
         certificates though, but it replaces that part.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 7 Dec 2015 19:29:22 +0000

> On Dec 7, 2015, at 12:07 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Michael, I failed to parse your response. 

Are you agreeing with Toerless’ argument that the new device should be a responder? 

Or, are you arguing that the new device should initiate the bootstrapping; but do so in a way that does not expose it is a new device? 

- max

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Mon, 7 Dec 2015 21:27:43 +0000

Mind to explain why you think grasp is outside the scope for constrained devices ? With cbor encoding its comparable in compactness to coap, right ?

Sent from my Samsung Captivate Glide on AT&T

Michael Richardson <[email-masked]> wrote:

---

From: peter van der Stok <[email-masked]>
Date: Tue, 08 Dec 2015 12:46:12 +0100

> devices, we cannot assume that anything at all has been configured or
Yes, but there is a minimum set of services on which you rely: e.g. UDP, 
DNS, ..
The discovery alternatives cited by toerless impress me as a list of 
services of which at least one must be present.

Therefore my consideration that for something as basic as Service 
discovery, some industries may regret that they need for example mDNS 
next to their favoured discovery service e.g. Resource Directory.
Faced with this choice they may decide that mDNS is not wanted but 
replaced by RD; and the Anima code in their products is adapted for that 
choice; while maintaining interoperability with ANIMA routers in all 
other respects.

Peter

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 8 Dec 2015 22:09:23 +0000

> On Dec 8, 2015, at 4:46 AM, peter van der Stok <[email-masked]> wrote:
> 
> 
> Yes, but there is a minimum set of services on which you rely: e.g. UDP, DNS, ..
> The discovery alternatives cited by toerless impress me as a list of services of which at least one must be present.

Perhaps an interesting path is like so:

An instantiated anima network MUST support “x”. This allows all devices to know the minimal thing they need to support. 
An instantiated anima network MAY support additional methods such as… “w, y and z”. 

> Therefore my consideration that for something as basic as Service discovery, some industries may regret that they need for example mDNS next to their favoured discovery service e.g. Resource Directory.
> Faced with this choice they may decide that mDNS is not wanted but replaced by RD; and the Anima code in their products is adapted for that choice; while maintaining interoperability with ANIMA routers in all other respects.

So long as there is a fallback that new devices can always use to join the anima network — even if it isn’t the most efficient method. 

- max

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Dec 2015 17:37:47 -0500

Max Pritikin (pritikin) <[email-masked]> wrote:
    >> This is one reason I'd like the new device to do things that
    >> configured devices do regularly.  So sending out a multicast IKEv2
    >> INIT might really make sense here.  Every device should do it every 5
    >> to 15 minutes.
    >>
    >> A new device will either send them, or receive them.  Either way, it
    >> can respond and within the privacy of IKEv2, can do something.  That
    >> doesn't you can't use a proxy to get things through: the resulting

    > Are you agreeing with Toerless’ argument that the new device should be

No. I'm saying that a new device should do as little as possible to call
attention to itself, and should prefer to do things that all other devices
are already doing.

    > Or, are you arguing that the new device should initiate the
    > bootstrapping; but do so in a way that does not expose it is a new
    > device?

For non-challenged (IoT) devices on non-challenged networks, the new device should
initiate and drive the bootstrapping.

It would be best if this communication was indistinguishable from other ACP
communication to an outsider.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 8 Dec 2015 23:48:42 +0000

> On Dec 8, 2015, at 3:37 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> attention to itself,

Ok, sounds like you’re agreeing with the threat but not necessarily the suggested mitigation.

> and should prefer to do things that all other devices
> are already doing.

I’m partially convinced that its worth minimizing how much a device “sticks its neck out” but once bootstrap is initiated I don’t think hiding the exchange is very easy nor worth the effort.

> communication to an outsider.

This can only occur if bootstrapping is over a “provisional” ACP. I’m uncomfortable with having GRASP and ACP include special cases for bootstrapping. My gut feel is that the simplicity of a specific bootstrapping sequence — even if identifiable — is preferable. 

A *non-privacy* preserving bootstrapping is preferable from a certain point of view. I want my autonomic network to track and identify any overlapping autonomic bootstrapping to domains I don’t recognize. 

- max

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Dec 2015 13:32:36 +1300

> A *non-privacy* preserving bootstrapping is preferable from a certain point of view. I want my autonomic network to track and identify any overlapping autonomic bootstrapping to domains I don’t rec…

I *really* don't see how the first step can be anything other than a
recognizable unencrypted multicast probe, whether it is sent by the joiner or
by some node that is already trusted. You could require that the unencrypted
probe includes a public key so that a unicast response can be encrypted; but
neither end is authenticated at that stage.

   Brian

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 9 Dec 2015 12:58:57 +0000

> >> For non-challenged (IoT) devices on non-challenged networks, the new
> >> device should initiate and drive the bootstrapping.
> >>
> >> It would be best if this communication was indistinguishable from
> >> other ACP communication to an outsider.
> >
> > This can only occur if bootstrapping is over a “provisional” ACP. I’m
> uncomfortable with having GRASP and ACP include special cases for
> bootstrapping. My gut feel is that the simplicity of a specific bootstrapping
> sequence — even if identifiable — is preferable.
> >
> > A *non-privacy* preserving bootstrapping is preferable from a certain
> point of view. I want my autonomic network to track and identify any
> overlapping autonomic bootstrapping to domains I don’t recognize.
> 
> by some node that is already trusted. You could require that the
> unencrypted probe includes a public key so that a unicast response can be
> encrypted; but neither end is authenticated at that stage.

I agree with Brian. New node and proxy need find each other, this invariably will involve some mcast probe. And, mcr, I think also your IKE proposal included IKE mcast packets initially, right? So also that is not "normal" and will be detected. I think trying to hide the process is impossible, thus we shouldn't even try to optimise toward it, but focus on minimising disclosure. 

I think the optimum is: 
- if the proxy sends out minimal information. Probably just something identifying a domain. I don't see another way right now than doing this periodically. 
- if the new node sends nothing at all (ie just responds)

Michael

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 9 Dec 2015 13:08:39 +0000

> Therefore my consideration that for something as basic as Service discovery,
> some industries may regret that they need for example mDNS next to their
> favoured discovery service e.g. Resource Directory.
> choice; while maintaining interoperability with ANIMA routers in all other
> respects.

At the end of the day I personally don't care *how* a domain certificate gets onto a new device. 

Probably we should be more clear on this, draw a big line, and state that the domain enrolment process may be replaced by many other methods, and that's ok.

So for us here that means, AN must also work if the domain certificates are (for whatever reason) already on the devices. I.e., what happens later in the AN process must not depend on anything in the bootstrap process, except the PKI info. 

Michael

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Wed, 9 Dec 2015 05:12:34 -0800

> neither end is authenticated at that stage.

Brian:

Max'es original argument was to minimize the invention of new secure association
setup. So when you need a secure association for bootstrap, we rely on TLS for EST.
When we need a secure association for ACP/GRASP, we rely on (d)TLS (still have to
decide in detail how to do this).

If this argument makes sense to the team, then i think we do not need crypto
info in the multicast discovery, because the response will directly be the first
packets of (d)TLS for EST or ACP/GRAP - eg: nothing new needed.

The only idea i could think of was to include crypto information in the multicast
announcement not for the benefit of the security association itself, but for the benefit
of a third party observer that tries to ensure no attacker sends discoveries to prey
on defenseless unconfigured greenfield devices.

I am happy about any new valuable crypto we can put into the discovery, i just
want to make sure we can be precise about the attack vector it helps to protect
against.

Cheers
    Toerless

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Wed, 9 Dec 2015 05:22:24 -0800

Michael:

Lets assume we replace EST bootstraap with "a guy with a USB stick feeding
manually domain certs to greenfield devices".

a) I agree that we would want to make sure our protocols are set up so that even such
   a device could perfectly bring up ACP afterwards and continue with the rest
   of autonomic functions (GRASP inside ACP, agents,...). 

b) I don't think we would want to call such a device "autonomic". It's partial
   autonomic at best. But yes, it may be perfectly valid and relevant to some
   industries.

If you agree, then the problem is IMHO primarily in the reference model calling
out that devices that for one reason or the other can not / want-not implement
the whole ANIMA suite can perfectly well implement just parts of it, because
ANIMA is defined such that the different building blocks are modular. Just that
such a device is only "partial-autonomic" (or  whatever you think is a good
naming to distinguish it from a truely autonomic device).

Btw: This also goes the other way, eg: it would IHO make sense that the bootstrap
spec can be deplpoyed on devices that do not want any further AN functions after
the certificates are enrolled. I think that option is also something we want to
explain in the bootstrap draft.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Dec 2015 07:59:33 +1300

On 10/12/2015 02:12, Toerless Eckert (eckert) wrote:
...
> want to make sure we can be precise about the attack vector it helps to protect

I very much agree with that. I wasn't actually saying we must add a public
key for the first exchange, just that we *could*. Actually the attack that really
puzzles me is this one:

Alice: Hello everybody, I want to join.

Bob: Hi Alice, I'll be your proxy today.
Eve: Hi Alice, I'll be your proxy today.

How does Alice know to listen to Bob and ignore Eve?
At that point she has no keys or certificates for Bob.

   Brian

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Wed, 9 Dec 2015 11:23:13 -0800

Alice never knows until later.

a) Lets assume we're talking bout announcements by Bob/Eve to connect to their ACP.

   Minimally, Alice has no idea whom it wants to connect to. So it simply starts
   let's say dTLS to Bob and Eve. Alice will then figure out whether Bob and.or
   Eve have domain certs for the same domain Alice is in. If not, Alice (or Bob/Eve)
   will drop the dTLS connection.

   We could try to optimize by announcing Bob/Eve's domain certs into the
   discovery messages. This would save some unnecessary connection attempts by
   Alice. No strong opinions.

b) Lets assume we're talking about announcements by Bob/Eve to be enrollment proxies.

   So now Alice is not in a domain and will set up ESP "randomnly" to Bob and/or Eve.

   If we do not have a MASA, then Alice is really at the mercy of
   The guy who plugs Alice's cable into some network connection.
   "Do not plug into an untusty socket".

   Aka: Alice tries EST to Bob. Bob proxies to Bobs domain registrar which
   checks Alices serial number and decides that Alice does not belong to Bobs domain.

   Alices continues on to build EST to Eve. and may get accepted into domain there.

   Aka: Both Bob and Eve belong to friendly domains only accepting devices
   they know they own.

   If we do have a MASA, Alice can feel more secure. So it connects to Eve,
   and Eve 's domain registrar wants to have Alice - even thoug alice doesn't below
   to Eves domain, but Eve is evil in this case. Alice will only accept enrollment
   when Eve is producing to Alice a ticket from the MASA stating that Alice belongs
   to Alices domain. And Alice trusts this ticket because it ultimately came from
   a MASA that must belong to Alices manufacturer. And ensures that the manufacturer
   is at least logging that Eve's domain/registrar is claiming to own Alice. 

   I can't see how Bob/Eve announcing their certs here would help Alice at all
   before establishing the EST connection.

Cheers
    Toerless

   Mr. Carpenter wanted to have the insecure enrollment option without MASA
   (and eg: ciscos autonomic solution also does this, so inse)like alsoeg: cisco customers in our c(and Cisco customers) wanted to have the
   
   These announcemments could contain Bob/Eves domain certificates.

   Alice can now quickly validate that it wants to connect Bob
If this is not for bootstrap but announcements to connect ACP,
then
So, if this was an announceme
Irr
So, if this is
Alice would not know. Alice would (randomnly) build 

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Dec 2015 15:17:26 -0500

> bootstrapping. My gut feel is that the simplicity of a specific
    > bootstrapping sequence — even if identifiable — is preferable.

If we believe that a device could belong to multiple ACPs (see my other
post in reply to Brian for some reasons for an intra-ISP ACPs), then having
an extra tunnel up, on a "disconnected" VRF, for a joining device is not a
big deal, I think.

    > overlapping autonomic bootstrapping to domains I don’t recognize.

Assuming that we use some non-private way to discover the enrollment proxy,
and we use (D)TLS 1.3, then observers would only see that there was a
bootstrap occuring.  They would observe the address of the enrollment, which
they might realize was not their own.

A multicasted IKE_INIT plus ACP would result in a tunnel with a device which
is not a recognized device, so would reveal the same amount of information to
an IDS.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Dec 2015 15:19:40 -0500

> neither end is authenticated at that stage.

Yes, that's true.
The point isn't that it's other than unencrypted multicast probe.

The point is that if this unencrypted multicast probe is a normal part of ACP
operation, then it is not obvious to (passive!) malicious observers which
device is actually bootstraping vs helping.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Dec 2015 15:48:45 -0500

Michael Behringer (mbehring) <[email-masked]> wrote:
    > I agree with Brian. New node and proxy need find each other, this
    > invariably will involve some mcast probe. And, mcr, I think also your
    > IKE proposal included IKE mcast packets initially, right? So also that
    > is not "normal" and will be detected. I think trying to hide the
    > process is impossible, thus we shouldn't even try to optimise toward
    > it, but focus on minimising disclosure.

Autonomic nodes will be regularly looking for other autonomic nodes on all
links in order to form redundant links for the ACP to use.  This is how the
adjacency table will be filled out.

We have a wide variety of possible multicasts available for populating the
advancy table. (And we should pick one, not many)
        1) NDs
        2) RPL DIS/DIO messages
        3) insecure-GRASPs
        4) mDNS

The advantage of doing this with IKEv2 (or TLS1.3) is that the identities
(and therefore bootstrap state) of each end point is only revealed within the
privacy of the initial DH.  [This is still subject to active eavesdropping!]

    > I think the optimum is:
    > - if the proxy sends out minimal information. Probably just something
    > identifying a domain. I don't see another way right now than doing this
    > periodically.

Well, my process would like:
      1) a multicast packet saying, "I'm an autonomic node" is sent out.
         It would have no domain or other identifying information.
         IKEv2 SA_INIT look something like:

IPv6 (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 864)
    fe80::3a60:77ff:fe38:e647.500 > ff02::1a.500: isakmp 2.0 msgid 00000000: parent_sa ikev2_init[I]:
    (sa: len=504
        (p: #1 protoid=isakmp transform=4 len=44
            (t: #1 type=encr id=aes (type=keylen value=0080))
            (t: #2 type=integ id=hmac-sha )
            (t: #3 type=prf id=hmac-sha )
            (t: #4 type=dh id=modp2048 ))
            ... see https://goo.gl/IHm6BJ for more details)
    (v2ke: len=256 group=modp2048)
    (nonce: len=16 data=(20989d37a814a64d8ff0...d320e9e3000000104f45706c75746f756e697430))
    (v2vid: len=12 vid=OEababababab)

2) a node seeing this, and wanting to establish a tunnel with that
      node, (whether to run an ACP over it, to offer to bootstrap it, or
      because it needs to be bootstraped), would reply, asking for the
      initiator to provide an IKEv2 cookie.
      (This acts as a sender address validation much like TCP SYN/ACK.
      see section 2.6 of rfc7296)

IPv6 (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 864)
    fe80::3a60:c0ff:ffee:babe.500 > fe80::3a60:77ff:fe38:e647.500: isakmp 2.0
    msgid 00000000: parent_sa ikev2_init[R]
    (cookie: COOKIE)

3) original initiator, seeing a new peer, replies with a new initiation,
    including the cookie as provided.

IPv6 (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 864)
    fe80::3a60:77ff:fe38:e647.500 > fe80::3a60:c0ff:ffee:babe.500: isakmp 2.0
    msgid 00000000: parent_sa ikev2_init[I]:
    (cookie: COOKIE)
    (sa: len=504
        (p: #1 protoid=isakmp transform=4 len=44
            (t: #1 type=encr id=aes (type=keylen value=0080))
            (t: #2 type=integ id=hmac-sha )
            (t: #3 type=prf id=hmac-sha )
            (t: #4 type=dh id=modp2048 ))
            ... see https://goo.gl/IHm6BJ for more details)
    (v2ke: len=256 group=modp2048)
    (nonce: len=16 data=(20989d37a814a64d8ff0...d320e9e3000000104f45706c75746f756e697430))
    (v2vid: len=12 vid=OEababababab)
...

4) then responder replies, and the IKEv2 PARENT SA is alive, and one could do
   all sorts of things, including:
        a) turn on a one-hop prospective ACP to get to the enrollment proxy.
        b) use EAP-TLS as the proxy mechanism.
        c) use something else/new as the proxy mechanism within IKEv2.
        d) recognize the other party, and bring up a real ACP.

The brilliant part is that no observer can tell which of a,b,c,d is really
going on from outside, they just see port-500 and ESP packets, which all
they'd ever see of the ACP anyway.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Dec 2015 16:07:44 -0500

> manually domain certs to greenfield devices".

Yes, I've no problem with that.

    > of autonomic functions (GRASP inside ACP, agents,...).

I don't see a problem here.

    > autonomic at best. But yes, it may be perfectly valid and relevant to some

It's part of the ACP, and it could participate in lots of self-healing
efforts.  So, it's autonomic.   What it isn't is *zero-touch*.

    > explain in the bootstrap draft.

Yes.  That's how I view IoT devices (such as in the 6tisch space) --- they
will do much of the bootstrap mechanism, but they won't build an ACP, and
won't run GRASP.

Perhaps, ditto HomeNet devices.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Dec 2015 18:49:37 -0500

> will drop the dTLS connection.

I don't know why you write *TLS here. There is no specification for running
IPv6 over TLS.

    > So now Alice is not in a domain and will set up ESP "randomnly" to Bob and/or Eve.

I think you mean, EST?

    > "Do not plug into an untusty socket".

We can do things without a MASA, but the certificate validation chain is more complex.

    > to Alices domain. And Alice trusts this ticket because it ultimately came from

Here, where you write "Alices domain", you mean "Eve's domain"

    > before establishing the EST connection.

It could help if both Bob and Eve are part of the same domain, and so after a
failure with Bob, Alice would know to go on to Frank, skipping Eve.
But, I agree that it doesn't in general help, because neither Bob nor Eve's
certificate has any verifiable meaning to Alice.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 9 Dec 2015 18:28:52 -0800

Inline.

> I don't know why you write *TLS here. There is no specification for running

This is in the realm of ACP spec to resolve i think. Let me just remove this discussion
from this thread here by saying we firsst set up a TLS connection for GRASP, then
GRASP negotiates the secure transport for ACP packets, eg: MTI is IPsec. (I prefer
dTLS for ACP packets because of code size, but that's yet another derailing discussion).

It is now the TLS security exchange that will make Alice trust Bob/Eve and vice versa. Or
not, in which case the connection would be dropped. 

And, oh, by the way. Here is more generically how i think of "optional" parameters
for the discovery:

There are things that would make the TLS connection setup fail. Alice vs. Bob/Eve
could be in different domains. Or Bob/Eve certificate might have changed, or
Bob/Eve had a broken clock backup battery and thinks its 1990. Or there was an
internal redundancy failover that was not completely stateful, so Bob/Eve would like
connections rebuilt. If any of this gets fixed/changed, Bob/Eve would hope that Alice
will try to reconnect periodically after it failed.

Now, if Bob/Eve want to be friendly, they could
try to figure out if any relevant elements for the successfull mutual TLS set have
changed (such as above), and if they have changed, they will signal in their discovery that
there was change. In Multicast PIM we call this parameter of discovery (Hello) a GenID. 
There it was pec'ed only for internal redundancy failover or reboot, but IMHO its a more
generally applicable concept.  It's just a number thats changed. Eg: Timestamp of 
relevant last change.

In result, Alice would not need to periodically try to reconnect, but only when there is a 
GenID change. And of course we would need to specify a minimum interval for reconnection 
attempts in case Bob/Eve are evil and continuosly change change GenID. Maybe Alice wants 
to even do backoff in case a candidate neighbor connection fails, its GenID changes,
connection attempt still fails. And maybe still do a periodic re-connection attempt
after a longer period even if GenID has not changed.

Instead of letting the sending node figure out itself all the possible changes
it has had into a single GenID, it could also explicitly announce those parameter
values, like explicitly announcing domain name into discovery. But the goal would just
be to further optimize the non-need for another TLS connection attempt by Alice. SO
we can discuss if thats worth it.

In summary: I think what we put as parameters into the discovery only serves to
manage how to do re-connects of the following (TLS) security association. 

>     > So now Alice is not in a domain and will set up ESP "randomnly" to Bob and/or Eve.

ETYPO. Thanks.

> We can do things without a MASA, but the certificate validation chain is more complex.

Well, lets not call it MASA for a second but let me just generalize the two
conditions:

Alice was sold to some owner X. IN general, it can not have a trust point for
an arbitrary owner X. Instead it can only have trust-points for eg: its manufacturer
and whatever trusted third-parties the manufacturer burned trustpoints into Alice's firmware.

In the "insecure" case, the manufacturer and its trusted third-parties are too lazy to
set up any backend functions to make Alice confident that it belongs to X (which in
Max'es definition really is "Alice feels confident that its manufacturer or one of
its trusted henchmen will remember that Bob/Eves domain claims to own Alice). In the
"secure" case, they do this. These backend functions could be a MASA or maybe something
else. But i thought the way Max has defined MASA it should be a good superset of
any possible ways to give Alice this confidence. Not sure though. Hopefully Max will
chime in.

> Here, where you write "Alices domain", you mean "Eve's domain"

Right.

> failure with Bob, Alice would know to go on to Frank, skipping Eve.

There are probably like for ACP also for bootstrap reasons for it to fail via Bob
that would not apply to Eve even if Bob/Eve are in the same domain.

> certificate has any verifiable meaning to Alice.

Right.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 9 Dec 2015 18:47:45 -0800

> I don't see a problem here.

Well, i was arguing that for optimization we could have a single GRASP discovery
message to indicate bot ACP-service (oops: objective ;-) (aka: you can build ACP to me)
as well as bootstrap-proxy objective. If your partial-AN device only does one
of those two things then the device would of course only announce the objective it
does support. So yes, even with optimization i don't see an issue, but it's worthwhile
to remember the "partial device" aspect and continue to vet the design against it.

> efforts.  So, it's autonomic.   What it isn't is *zero-touch*.

Haha... Ok. I like these naming discussions more than i should:

I think "zero-touch" is a required part of day-0 autonomic behavior. Agreeably,
unless we have routers that double as drones/robots, and physcially self-connect
to the network (into the right place, by cable), the bootstrap itself is necessary
but may considered not to be sufficient enough so the device can be called day 0 autonomic.

I thought we call humans autonomic/autonomous, do we ? Down to which age ? 
I should stop here ;-)

> will do much of the bootstrap mechanism, but they won't build an ACP, and

Haven't had enough engaement to have a founded opinion.
> Perhaps, ditto HomeNet devices.

Yes, good example. 

Cheers
    Toerless

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Wed, 9 Dec 2015 18:51:36 -0800

> device is actually bootstraping vs helping.

If we do not distinguish bootstrap vs ACP in the discovery messages we may
also make the behavior of partial-autonomic devices that only care about one of
those things more obfuscated. Aka: I should be prepared to get eg: EST connection
attempts all the time even though i don't do it, or ACP connection attempts
even though i don't do that. 

I don't think we buy useful security by obfuscating what objectives we offer.

Cheers
   Toerless

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Wed, 9 Dec 2015 19:01:34 -0800

On Tue, Dec 08, 2015 at 05:37:47PM -0500, Michael Richardson wrote:
>     > Are you agreeing with Toerless??? argument that the new device should be
>     > a responder?
> 

My argument why it should rather do as little as possible (nothing) to call
attention to itself (which i think is different to what you're saying) is that
the attacker can also observe waht everybody else is doing and attack everybody
else. Only that everybody else will likely have stronger defenses having been already
enrolled and hopefully gotten software upgrades and hardening through intent/config/whatever.

But, this is just an optimization proposal from my side. No strong opinions.
Would just like to hear why it may not be a worthwhile enough optimization if you think it ain't.

Cheers
    Toerless

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 17 Dec 2015 22:26:55 +0000

> -----Original Message-----
> From: Toerless Eckert (eckert)
> Sent: 09 December 2015 14:22
> To: Michael Behringer (mbehring) <[email-masked]>
> Cc: [email-masked]; Brian E Carpenter
> <[email-masked]>; [email-masked]
> Subject: Re: [Anima-bootstrap] anima-bootstrap: Bootstrap proxy discovery
> options
> 
> 
> Michael:
> 

We agree. 
 
>    autonomic at best. But yes, it may be perfectly valid and relevant to some

I don't care what we call it. "fully autonomic" won't happen for a long time anyway.

But aside of the naming, I really think the key value of AN is way beyond bootstrap. Not today, but in the future. So frankly, if someone wants to use another method to bootstrap, I really don't care. 

> If you agree, then the problem is IMHO primarily in the reference model
> calling out that devices that for one reason or the other can not / want-not
> implement the whole ANIMA suite can perfectly well implement just parts of
> it, because ANIMA is defined such that the different building blocks are
> modular. Just that such a device is only "partial-autonomic" (or  whatever you
> think is a good naming to distinguish it from a truely autonomic device).

Yup. we can do that. 

> Btw: This also goes the other way, eg: it would IHO make sense that the
> bootstrap spec can be deplpoyed on devices that do not want any further AN
> functions after the certificates are enrolled. I think that option is also
> something we want to explain in the bootstrap draft.

True. And we do already have customers that are JUST interested in the bootstrap, Sprint was one case. Remember, they wanted to disable AN after bootstrap!! 

All I'm saying, let's be practical, not religious. :-) 

Michael

> > > discovery, some industries may regret that they need for example
> > > mDNS next to their favoured discovery service e.g. Resource Directory.
> > > replaced by RD; and the Anima code in their products is adapted for
> > > that choice; while maintaining interoperability with ANIMA routers
> > > in all other respects.
> >
> > Probably we should be more clear on this, draw a big line, and state that
> the domain enrolment process may be replaced by many other methods,
> and that's ok.
> >
> > So for us here that means, AN must also work if the domain certificates are
> (for whatever reason) already on the devices. I.e., what happens later in the
> AN process must not depend on anything in the bootstrap process, except
> the PKI info.
> >
> > Michael
> >
> > > Peter
> > >

---

From: peter van der Stok <[email-masked]>
Date: Fri, 18 Dec 2015 08:10:45 +0100

Hi all,

+1 for me.
I like the direction of this discussion given my background.

Peter

Michael Behringer (mbehring) schreef op 2015-12-17 23:26:
>> a) I agree that we would want to make sure our protocols are set up so 
>> that
>> even such
> But aside of the naming, I really think the key value of AN is way
> beyond bootstrap. Not today, but in the future. So frankly, if someone
> wants to use another method to bootstrap, I really don't care.
> 
> True. And we do already have customers that are JUST interested in the
> bootstrap, Sprint was one case. Remember, they wanted to disable AN
> after bootstrap!!
>