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

[Michael Richardson <[e-mail]>]

Michael Behringer (mbehring) <[e-mail]> 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.
    > - if the new node sends nothing at all (ie just responds)

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.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-