Subject: [Anima] comments on current drafts

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Nov 2015 22:05:26 -0500

I spent most of my 11h trip home on Monday catching trying to empty my list
of drafts to read...  I have a series of comments on the documents which I'll
post as seperate threads.

I read through:
  - draft-ietf-anima-grasp-01
  - draft-ietf-anima-autonomic-control-plane-01
  - draft-behringer-anima-autonomic-addressing-02
  - draft-liu-anima-grasp-distribution-00
  - draft-ietf-anima-autonomic-control-plane-01
  - draft-behringer-anima-reference-model-04

Reading the drafts I get a profound sense of dis-unity...
It's about ACP vs GRASP, and how/where we do things.

I think we need a virtual interim or something like that where we can talk
for a longer period of time in a smaller group.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 2015 17:10:56 +1300

> It's about ACP vs GRASP, and how/where we do things.

Can you try to explain where you see a disconnect? Because I don't.
The ACP provides a secure private Internet for ANs to use as they
wisk, and GRASP runs over the ACP to offer higher level messaging
functions to the ANs.

Right now all that GRASP seems to need from the ACP is a status bit
saying "ACP is up" and a socket API. It might need to peek into the
adjacency table, but I'm not even sure about that.

True, this chases its own tail a bit if GRASP is used for initial discovery,
and that does need to be tied down.

> for a longer period of time in a smaller group.

We certainly need to understand what's not fitting together.

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 11 Nov 2015 08:37:40 +0000

Hi, Michael R,

Thanks for your contributions. We can certainly arrange virtual interim meeting. However, the difficulty, let's say only GRASP and ACP only, is people belong to different time zone. You are in northern American. Brian is in New Zealand. Michael B is in Europe. This has not mentioned that Bing and I are in Chinese time zone.

You can suggest a meeting time. But I guess more feasible solution is to split the meeting into even smaller: you can have meeting with Brian, then have another one with Michael B.

Meanwhile, discussion through email may also efficient. Although we may have type a lot, but we could clear up our ideas during the typing.

Regards,

Sheng

>-----Original Message-----
>From: Anima [mailto:[email-masked]] On Behalf Of Michael
>Richardson
>Sent: Wednesday, November 11, 2015 11:05 AM
>To: [email-masked]
>Subject: [Anima] comments on current drafts
>
>

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 11 Nov 2015 15:06:36 +0000

> On Nov 10, 2015, at 9:10 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Can you try to explain where you see a disconnect? Because I don’t.

> and that does need to be tied down.

This is what I called out during Yokohama as well. Is it "ACP then GRASP” or “GRASP then ACP then GRASP again”? Clearly I have a bootstrapping perspective but maybe Michael is thinking along the same lines. 

- max

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2015 08:18:51 +1300

Hi Max,

> This is what I called out during Yokohama as well. Is it "ACP then GRASP” or “GRASP then ACP then GRASP again”? Clearly I have a bootstrapping perspective but maybe Michael is thinking along the sa…

So, the reason I haven't been rushing to update the GRASP document following the
very helpful discussion in Yokohama (which I followed thanks to a perfect
performance by Meetecho) is that I am teaching myself Python by trying to write
a prototype GRASP implementation instead. It's an instructive process and I hope
it will find bugs in the GRASP design and make the resolution of the open issues
much easier.

As far as I can see so far, when the GRASP  protocol engine comes up, the first
thing it will do is ask the ACP "are you up?". Assuming the ACP says no, GRASP
knows that it is running insecurely. Apart from that its discovery mechanism will
be available and if either the secure bootstrap mechanism or the ACP wants to
execute GRASP discovery it can do so. That would imply that the bootstrap and
the ACP each supports a notional GRASP objective to allow discovery; these could
be objectives with no value field. For example, assume every bootstrap relay supports
an objective called "bootRelay" and every ACP engine supports an objective called
"ACP".

Then when each bootstrap relay agent comes up it tells its local GRASP engine
that it's available to be discovered. In my prototype that would use a function
called grasp.register_obj(). Any device that wanted to find a relay agent would ask
its local GRASP engine using a function called grasp.discover(). ACP engines would
discover each other similarly. What they do when they've found each other is
out of scope for GRASP.

Clearly at that stage everybody is using non-ACP addresses (link-local mainly)
until the bootstrap phase is over and the ACP is established.

Does this make any sense?

Of course there is a security issue during the non-ACP discovery phase, as
noted in the GRASP draft:

      If GRASP is used temporarily without an external security
      mechanism, for example during system bootstrap (Section 3.3.1),
      the Session ID (Section 3.6) will act as a nonce to provide
      limited protection against third parties injecting responses.

   Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 11 Nov 2015 22:27:30 +0000

> On Nov 11, 2015, at 12:18 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Max,
> 

And is of course *much more fun* than working on the document text. :)

> knows that it is running insecurely.

According to s3.3.2:
"   When running without an ACP, TLS MUST be supported and used by
   default, except for multicast discovery messages.  DTLS MAY be
   supported as an alternative but the details are out of scope for this
   document.”
But this can’t happen until bootstrapping is complete.

> Apart from that its discovery mechanism will

I think so. Doesn’t mean I don’t have questions though ;)

>      limited protection against third parties injecting responses.

I understand the intention of using the SessionID as a nonce. 

There are three questions I’ve got: 
1) What is GRASP providing bootstrapping that isn’t provided via other methods? Is the argument that the internal API methods to a GRASP library makes it easier to code an agent than, for example, having an agent open the socket directly? 

2) How complex is it to use GRASP as the discovery method? If clients perform DNS or DHCP or other discovery methods in addition to GRASP how much additional code do they need to perform GRASP itself? I admit I’m trying to think here about netconf and other groups that might want to do discovery but not be required to do the rest of autonomic (e.g. GRASP, ACP etc).  

3) Does the SessionID method actually work? (Assuming the above MUST about TLS isn’t applied of course).

- max

---

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

Comments in line. This is good, we're getting to the real questions...

> But this can’t happen until bootstrapping is complete.

Yes (because nodes won't have certs yet). This is one of the reasons that
I think the non-ACP mode of GRASP is in general something we have to declare
as TBD for now. So it means (I think) that all we have to work with is insecure
discovery. All other GRASP operations need to fail until acp.status == True
or we can successfully start TLS.

> 1) What is GRASP providing bootstrapping that isn’t provided via other methods? Is the argument that the internal API methods to a GRASP library makes it easier to code an agent than, for example,…

If we are only talking about discovery, that is all you get. I have no
religion here - if you have another discovery mechanism, that's fine
by me.

Of course we could add an explicitly insecure message mode to GRASP,
so that you get whatever the GRASP API turns out to be instead of
a basic socket. That wouldn't be hard; whether it's useful is another
matter.

> 2) How complex is it to use GRASP as the discovery method? If clients perform DNS or DHCP or other discovery methods in addition to GRASP how much additional code do they need to perform GRASP itse…

Well, I'm hoping it will come down to a couple of calls. I really don't want to go
into details until I've made some code run, but what I'm thinking is there would
mainly be these calls:

register_asa(asa_name)      # register the calling ASA with GRASP
                            # (bootstrap and ACP would pretend to be ASAs)
register_obj(objective)     # register an objective so that other nodes can discover you
                            # "bootRelay" and "ACP" for example
discover(objective, timeout)# discover other ASAs supporting the objective
list_peers(objective)       # get a list of locators of the discovered ASAs

> 3) Does the SessionID method actually work? (Assuming the above MUST about TLS isn’t applied of course).

Well, Joel Halpern noticed a design error that we need to fix. I decided to
defer fixing it until I have tried to code it, but my co-authors may have
some ideas. (The error is that we didn't discuss the issue of two different
nodes choosing the same SessionID value. That's low probability in a 24 bit
space but it's still a design flaw.)

   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 12 Nov 2015 03:47:27 +0000

Hi all,

> From: Anima [mailto:[email-masked]] On Behalf Of Max Pritikin
> (pritikin)
...
> This is what I called out during Yokohama as well. Is it "ACP then GRASP” or
> “GRASP then ACP then GRASP again”? Clearly I have a bootstrapping
> perspective but maybe Michael is thinking along the same lines.

Apart from ASAs, we also need the following signallings:
- a Discovery mechanism during bootstrapping (Boot-Discovery)
- a Discovery/Negotiation mechanism during ACP establishing (ACP-DisNeg)

The GRASP might have the security state:
- no security at all (GRASP-NonSec)
- TLS/DTLS secured (GRASP-(D)TLS)
- Running in ACP, mostly for ASAs communication (GRASP-ACP)

If the Boot-Discovery choose GRASP, then I guess we need to make the GRASP-NonSec valid as well(in current draft, there is no choice for non-secured GRASP). Because it would be difficult for GRASP to gain (D)TLS protection without the bootstrapping ready.
However, as Max said, it seems bootstrapping prefer other discovery mechanisms than GRASP? I need to do a homework to figure out the signaling requirements of bootstrapping. (Max, if you could give me some hint, that would be very helpful. Many thanks.)

In ACP draft, it specifies that the ACP-DisNeg MUST be secured. So, if the ACP-DisNeg is GRASP, it just assumes GRASP-(D)TLS in use, which is applicable after bootstrapping, is there any gap?

Best regards,
Bing

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2015 21:00:08 -0800

My quick summary of how i could imagine the connection:

A. Unenrolled node:

1. GRASP1 (boring): L2 discovery of neighboring (not enrolled) AN nodes:

   instance of unsecure, unprotected L2-only GRASP.
   Enrolled node periodically sends L2 IP multicast objective
   discovery multicast "AN-node-who-wants-to-get-enrolled"

   AN nodes willing to enroll send unicast message back

   not sure if we want another unicast exchange round to prohibit
   some DoS attacks from other nodes on the same LAN.

   TBD: any attributes to include at "app-level", eg: SUDI or the
   like, might help, not sure.

2. Bootstrap continues with an EST/TLS connection where enrolled
   node acts as TLS proxy. 

   Not sure if there further cases for GRASP in the bootstrap process
   or if everything we need would be within EST. We do know that
   we want specific details in the certificate assigned. Not sure
   enough about EST details yet.

B. Enrolled Nodes creating ACP between each other.

1. GRASP (boring): same as A.1, except that the two nodes discovery
   that they are claming both to be enrolled into same domain.

2. TLS (or dTLS ?) connection built between the two nodes.
   GRASP inside TLS connection, also just single-hop negotiating
   ACP tunnel mode.

   MTI ACP encryption: dTLS or IPsec. IPsec is logical, but
   talking to IOT folks it seems dTLS will be in every IOT
   device that has any security, so maybe dTLS is better lowest
   common denominator.

C. Primary GRASP instance inside ACP

   This instance will be protected by ACP and be network wide,
   eg: GRASP needs to forward hop-by-hop.

1. Main purpose for GRASP inside ACP for the ACP itself (everything
   else is for future autonomic agents):

   Service-discovery of registrar. Eg: the already enrolled AN node
   in A. acting as proxy for enrollment will learn IP-address of
   registrar via GRASP.

There are some open questions i have here as well, but lets see
if this is on the outset what we think it should be.

Cheers
    Toerless

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Nov 2015 11:34:48 -0500

Brian E Carpenter <[email-masked]> wrote:
    >> I spent most of my 11h trip home on Monday catching trying to empty my
    >> list of drafts to read...  I have a series of comments on the
    >> documents which I'll post as seperate threads.
    >>
    >> I read through: - draft-ietf-anima-grasp-01 -
    >> draft-ietf-anima-autonomic-control-plane-01 -
    >> draft-behringer-anima-autonomic-addressing-02 -
    >> draft-liu-anima-grasp-distribution-00 -
    >> draft-ietf-anima-autonomic-control-plane-01 -
    >> draft-behringer-anima-reference-model-04
    >>
    >> Reading the drafts I get a profound sense of dis-unity...  It's about
    >> ACP vs GRASP, and how/where we do things.

    > The ACP provides a secure private Internet for ANs to use as they wisk,
    > and GRASP runs over the ACP to offer higher level messaging functions
    > to the ANs.

I don't see this in the documents, and I have six half-written emails
explaining where I think the disconnects are...

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Thu, 12 Nov 2015 20:40:55 +0000

We thought that it would be better this way around because:

Already enrolled device can be less attacked, because it will not react to unsolicited messages.

Client device sitting in a non-an environment will not generate messages unnecessary in this environment, but just rspond.

Sent from my Samsung Captivate Glide on AT&T

Toerless,

I think that's about right. I would probably invert the logic
in stage 1 (an enrolled node responds to discovery multicast by
an unenrolled node) but that's a detail.

   Brian

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Thu, 12 Nov 2015 21:15:14 +0000

A registrar is the seed node

"Joel M. Halpern" <[email-masked]> wrote:
I am missing something in the description.

Initially, I assume, all nodes are unenrolled.
If the only way to get enrolled is to receive a message from an enrolled
node, then it seems that we simply stay in the state with all nodes
unenrolled.
So in either case, don't we need some way for two unenrolled nodes to
decide collectively taht they should declare themselves enrolled?

Yours,
Joel

On 11/12/15 3:40 PM, Toerless Eckert (eckert) wrote:
> Client device sitting in a non-an environment will not generate messages
> unnecessary in this environment, but just rspond.
>
>
>
>

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Thu, 12 Nov 2015 21:33:09 +0000

If the reference model is not enlightening enough about this, id recommend we first fix that doc up to capture this.

"Joel M. Halpern" <[email-masked]> wrote:
With the behaviors fragmented across the GRASP, ACP, and Bootstrap
documents, this is veyr hard to determine.
In particular, as far as I can tell the current bootstrap document does
not have Proxies advertising.  I missed where it said that a proxy must
be enrolled before it starts forwarding.  And the registrar is described
as responding to requests.

Yours,
Joel

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 13 Nov 2015 08:08:48 +0000

Yes we need to be clearer in both the reference draft and the bootstrap draft that a new node is passive, and waits to be invited to join a domain. 

The rest is actually there I think. Section 5 of the reference model says: 

If the node has bootstrapped into a domain (i.e., has a domain
      certificate), it will act as a proxy for neighboring nodes that
      need to be bootstrapped.

Maybe I need to add "only if ...", and be more explicit about the new node NOT being active. 

The rest of the logic is there, I think, however the reference draft doesn't specify protocols (yet). Do we want to include them now? 

Michael

> From: Anima [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 12 November 2015 22:40
> To: Toerless Eckert (eckert) <[email-masked]>; Brian E Carpenter
> <[email-masked]>
> Cc: Michael Richardson <[email-masked]>; [email-masked]
> Subject: Re: [Anima] comments on current drafts
> 
> No, the reference model document is not enlightening about this.
> 
> And if we are going to treat the reference model as reflecting WG agreement
> (a desirable state) shouldn't we adopt the document as a working group
> document instead of leaving it as an individual draft?
> 
> Yours,
> Joel
> 
> On 11/12/15 4:33 PM, Toerless Eckert (eckert) wrote:
> > If the reference model is not enlightening enough about this, id
> > recommend we first fix that doc up to capture this.
> >
> >
> >
> >
> > In particular, as far as I can tell the current bootstrap document
> > does not have Proxies advertising.  I missed where it said that a
> > proxy must be enrolled before it starts forwarding.  And the registrar
> > is described as responding to requests.
> >
> > Yours,
> > Joel
> >
> >> If the only way to get enrolled is to receive a message from an
> >> enrolled node, then it seems that we simply stay in the state with
> >> all nodes unenrolled.
> >>> Client device sitting in a non-an environment will not generate
> >>> messages unnecessary in this environment, but just rspond.
> >>>
> >>>
> >>>
> >>>
> >>> I think that's about right. I would probably invert the logic in
> >>> stage 1 (an enrolled node responds to discovery multicast by an
> >>> unenrolled node) but that's a detail.
> >>>
> >>>     Brian
> >>>
> >>>
> >>>> There are some open questions i have here as well, but lets see if
> >>>> this is on the outset what we think it should be.
> >>>>
> >>>> Cheers
> >>>>     Toerless
> >>>>
> >>>>>> I spent most of my 11h trip home on Monday catching trying to
> >>>>>> empty my list of drafts to read...  I have a series of comments
> >>>>>> on the documents which I'll post as seperate threads.
> >>>>>>
> >>>>>> I read through:
> >>>>> Right now all that GRASP seems to need from the ACP is a status
> >>>>> bit saying "ACP is up" and a socket API. It might need to peek
> >>>>> into the adjacency table, but I'm not even sure about that.
> >>>>>
> >>>>> True, this chases its own tail a bit if GRASP is used for initial
> >>>>> discovery, and that does need to be tied down.
> >>>>>
> >>>>>> I think we need a virtual interim or something like that where we
> >>>>>> can talk for a longer period of time in a smaller group.
> >>>>>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 13 Nov 2015 08:22:22 +0000

> Sent: 13 November 2015 02:01
> To: Brian E Carpenter <[email-masked]>; Toerless Eckert
> (eckert) <[email-masked]>
> This seems to require that all devices supporting the enrollment process,
> once they are enrolled, must emit a steady, if somewhat low rate, stream of
> advertisements so that new non-enrolled devices on the net will see such
> advertisements.
> 
> That seems unfortunate.

Why? 

If we're talking "autonomic", i.e., self-managing, there is no other way. If a network is really not centrally controlled (where someone explicitly tells the network where things have to happen), then network elements need to keep their eyes open on what's happening around them.

But this is generally true, also for enrolled devices in a fully established domain. 

We shouldn't distinguish between the discovery protocol for an un-enrolled device and one for enrolled devices. An enrolled autonomic node runs periodic, link local discovery. Every autonomic node (enrolled or not) listens. This is ONE protocol. The result of this feeds the adjacency table, and then, based on my state and my neighbor's state, different things will happen. This is what section 5 of the reference draft aims to clarify. 

I actually think apart from the fact that a new node is passive only, and an enrolled node actively sends discovery packets (see my previous message), all else is there. Would love specific feedback on section 5. 

Michael

> Yours,
> Joel
> 
> On 11/12/15 7:49 PM, Brian E Carpenter wrote:
> > On 13/11/2015 09:40, Toerless Eckert (eckert) wrote:
> > Well, yes, it will have to be a server in fact, listening for incoming
> > discovery multicasts, but that's OK: all GRASP nodes are both clients
> > and servers. Then once it starts the enrollment process, it stops
> > listening for that particular type of discovery.
> >
> > Not a problem for GRASP.
> >
> >     Brian
> >
> >>
> >>
> >>
> >>
> >>>>> empty my list of drafts to read...  I have a series of comments on
> >>>>> the documents which I'll post as seperate threads.
> >>>>>
> >>>>> I read through:

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 13 Nov 2015 08:43:08 +0000

> From: Anima [mailto:[email-masked]] On Behalf Of Liubing (Leo)
> Sent: 12 November 2015 04:47
> To: Max Pritikin (pritikin) <[email-masked]>; Brian E Carpenter
> > This is what I called out during Yokohama as well. Is it "ACP then
> > GRASP” or “GRASP then ACP then GRASP again”? Clearly I have a
> > bootstrapping perspective but maybe Michael is thinking along the same
> lines.
> 

I think it's not that complicated. 

GRASP in the ACP is the same GRASP running in the data plane. In one the context is secure, in the other not. But the protocol - as I see is - is the same. 

Discovery in the data plane, which feeds the adjacency table is insecure. It feeds the adjacency table. Meaning that the info in the adjacency table cannot be trusted, it's a table of "what nodes around me have claimed". 

We MAY also validate some info in the adjacency table, for example we could validate the SUDI of a new, not yet bootstrapped neighbour. This is why I added fields for "validity" in the table I presented in Yokohama. But I'm not sure that the benefit of this worth it. I somehow like the simplicity of the statement "the adjacency table cannot be trusted". 

Now every action a node takes on the adjacency table has to be clear that it's starting with potentially fake data. Therefore, the ACP bring-up, bootstrap, and whatever else we may want to do MUST secure. That means now that *IF* we use GRASP for bootstrap (I don't think this is decided yet?), in this particular context, GRAPS (or any other protocol we may choose) needs to be secured. 

Now the fact that the adjacency table may contain fake information gives us a security exposure: A node could at least force repeated negotiations (for example to establish the ACP). So we need the capability to rate limit or ignore a particular node, if we learn that it's malicious.

Do we agree with this statement that the adjacency table is fed by unsecured protocols and therefore cannot be trusted blindly? I think this is important to capture. 

Michael

> If the Boot-Discovery choose GRASP, then I guess we need to make the
> GRASP-NonSec valid as well(in current draft, there is no choice for non-
> secured GRASP). Because it would be difficult for GRASP to gain (D)TLS
> protection without the bootstrapping ready.
> However, as Max said, it seems bootstrapping prefer other discovery
> mechanisms than GRASP? I need to do a homework to figure out the
> signaling requirements of bootstrapping. (Max, if you could give me some
> hint, that would be very helpful. Many thanks.)
> 
> In ACP draft, it specifies that the ACP-DisNeg MUST be secured. So, if the
> ACP-DisNeg is GRASP, it just assumes GRASP-(D)TLS in use, which is
> applicable after bootstrapping, is there any gap?
> 
> Best regards,
> Bing

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 13 Nov 2015 09:20:52 +0000

> From: Michael Behringer (mbehring) [mailto:[email-masked]]
> Sent: Friday, November 13, 2015 4:43 PM
> To: Liubing (Leo); Max Pritikin (pritikin); Brian E Carpenter
> Cc: Michael Richardson; [email-masked]
> Subject: RE: [Anima] comments on current drafts
> 
> GRASP in the ACP is the same GRASP running in the data plane. In one the
> context is secure, in the other not. But the protocol - as I see is - is the same.
[Bing] Yes, exactly. I just wanted to list all the possibilities for ease of analysis.

> Discovery in the data plane, which feeds the adjacency table is insecure. It
> feeds the adjacency table. Meaning that the info in the adjacency table
> cannot be trusted, it's a table of "what nodes around me have claimed".
> 
> We MAY also validate some info in the adjacency table, for example we
> could validate the SUDI of a new, not yet bootstrapped neighbour. This is
> why I added fields for "validity" in the table I presented in Yokohama. But I'm
> not sure that the benefit of this worth it. I somehow like the simplicity of the
> statement "the adjacency table cannot be trusted".
> 
> Now every action a node takes on the adjacency table has to be clear that
> it's starting with potentially fake data. Therefore, the ACP bring-up,
> bootstrap, and whatever else we may want to do MUST secure. That means
> now that *IF* we use GRASP for bootstrap (I don't think this is decided yet?),
> in this particular context, GRAPS (or any other protocol we may choose)
> needs to be secured.
[Bing] For ACP bring-up, it mostly happens after the bootstrap, so I believe it won't be a problem for the GRASP to be secured(doing TLS/DTLS should not be difficult after bootstrap).
The only challenge I can see is how to secure GRASP before bootstrap. Even if bootstrap doesn't use GRASP, it is still a challenge for secured signaling before that.

Best regards,
Bing

> Now the fact that the adjacency table may contain fake information gives us
> a security exposure: A node could at least force repeated negotiations (for
> example to establish the ACP). So we need the capability to rate limit or
> ignore a particular node, if we learn that it's malicious.
> 
> Do we agree with this statement that the adjacency table is fed by unsecured
> protocols and therefore cannot be trusted blindly? I think this is important to
> capture.
> 
> Michael
> 
> > GRASP-NonSec valid as well(in current draft, there is no choice for
> > non- secured GRASP). Because it would be difficult for GRASP to gain
> > (D)TLS protection without the bootstrapping ready.
> > signaling requirements of bootstrapping. (Max, if you could give me
> > some hint, that would be very helpful. Many thanks.)
> >
> > In ACP draft, it specifies that the ACP-DisNeg MUST be secured. So, if
> > the ACP-DisNeg is GRASP, it just assumes GRASP-(D)TLS in use, which is

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Nov 2015 07:41:40 +1300

Bing,

> The only challenge I can see is how to secure GRASP before bootstrap. Even if bootstrap doesn't use GRASP, it is still a challenge for secured signaling before that.

As far as I can tell, you're correct that there are three modes:

Best: ACP is up, GRASP just sends packets
Medium: No ACP, GRASP must wrap sessions in TLS
Worst: No certificates available, GRASP is insecure.

The reason I was asking Michael some weeks ago about multicast support
in the ACP is because my understanding is that link-local multicast is
intrinsically insecure, so LL discovery messages are intrinsically
insecure. In any case, discovery before bootstrap is insecure, but
I guess the bootstrap design will assume that.

Regards
   Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 13 Nov 2015 18:54:35 +0000

I second this concern. A polling model like this is just as susceptible to attack (on the polling interval) as listening for a new device -- and involves the steady stream of announcements. 

Let's address any underlying security concern and optimize the initiator/responder independently. 

- max 

> On Nov 12, 2015, at 5:01 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> This seems to require that all devices supporting the enrollment process, once they are enrolled, must emit a steady, if somewhat low rate, stream of advertisements so that new non-enrolled devices on the net will see such advertisements.
> 
> That seems unfortunate.
> Yours,
> Joel
> 
>> and servers. Then once it starts the enrollment process, it stops listening
>> for that particular type of discovery.
>> 
>> Not a problem for GRASP.
>> 
>>    Brian
>> 
>>> 
>>> 
>>> 
>>>

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 13 Nov 2015 18:58:44 +0000

Inline,

> On Nov 11, 2015, at 7:47 PM, Liubing (Leo) <[email-masked]> wrote:
> 
> Hi all,
> 

I'm not sure the question you are asking. The new entity needs to establish a communication channel with the domain. The bootstrapping draft details a list of possible methods (and a proposed order). 

- max 
(mobile device)

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 13 Nov 2015 19:07:41 +0000

Inline,

> On Nov 13, 2015, at 10:41 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> Bing,
> 

The security considerations for a protocol that only sometimes runs over a secure transport is going to be painful. 

- Max

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Nov 2015 08:17:52 +1300

> The security considerations for a protocol that only sometimes runs over a secure transport is going to be painful. 

I think we will simply have to restrict operations in a specific way.
It seems inevitable to me that only very limited operations are allowed
before the bootstrap is complete. (I'm glad we're having this conversation,
because that thought has been at the back of my mind for a while.)

   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Nov 2015 16:32:47 -0500

When I read the ACP and GRASP drafts, one of the things that caused me 
difficulty was that ACP talks about using GRASP, and GRASP talks about 
using ACP.  Now, from reading the recent discussion it is clear that 
this is not a contradiction, but a descritpion of different phases of 
operation.

Would it be clearer to talk about GRASP-insecure with specific 
restrictions on what it can do and a focus on supporting the bootstrap 
process, and grasp-secure which is used later.  With ACP interaction 
more clearly described in terms of two different mechanisms that it 
interacts with?

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Nov 2015 11:36:38 +1300

On 14/11/2015 10:32, Joel M. Halpern wrote:
> When I read the ACP and GRASP drafts, one of the things that caused me difficulty was that ACP talks about using GRASP, and
> GRASP talks about using ACP.  Now, from reading the recent discussion it is clear that this is not a contradiction, but a
> descritpion of different phases of operation.
> 
> Would it be clearer to talk about GRASP-insecure with specific restrictions on what it can do and a focus on supporting the
> bootstrap process, and grasp-secure which is used later.  With ACP interaction more clearly described in terms of two different
> mechanisms that it interacts with?

Yes. I think most of that belongs in the reference model, with some specifics
in the GRASP and ACP drafts.

Regards
   Brian

>>>>> The only challenge I can see is how to secure GRASP before bootstrap. Even if bootstrap doesn't use GRASP, it is still a
>>>>> challenge for secured signaling before that.
>>>>
>>>>> [Bing] For ACP bring-up, it mostly happens after the bootstrap, so I believe it won't be a problem for the GRASP to be
>>>>> secured(doing TLS/DTLS should not be difficult after bootstrap).
>>>>> The only challenge I can see is how to secure GRASP before bootstrap. Even if bootstrap doesn't use GRASP, it is still a
>>>>> challenge for secured signaling before that.
>>>>>
>>>>> Best regards,
>>>>> Bing
>>>>>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 29 Nov 2015 18:21:21 -0500

Brian E Carpenter <[email-masked]> wrote:
    > As far as I can see so far, when the GRASP protocol engine comes up,
    > the first thing it will do is ask the ACP "are you up?". Assuming the
    > ACP says no, GRASP knows that it is running insecurely. Apart from that
    > its discovery mechanism will be available and if either the secure
    > bootstrap mechanism or the ACP wants to execute GRASP discovery it can
    > do so. That would imply that the bootstrap and the ACP each supports a
    > notional GRASP objective to allow discovery; these could be objectives
    > with no value field. For example, assume every bootstrap relay supports
    > an objective called "bootRelay" and every ACP engine supports an
    > objective called "ACP".

There are really two scenarios ACP.areyouup = false.

1) before bootstrap.
2) when device is not connected to any other ANIMA connected device.

Those are not the same thing.
And for #2, this condition can persist on a per-interface basis for a long time.

We also, in the context of running GRASP insecurely on a particular
interface, need to think hard about what GRASP might reveal from a privacy
point of view.
Some interfaces may *never* be used for the ACP, they could be customer facing, etc.
Yet, we need to periodically see if as a result of some cables being
re-arranged, there is now a machine that *is* part of the domain.  An example
here would be where an ISP's switches from using the ISP provided CPE to
their own CPE, or back again.

We also need to consider if/how we run on virtual interfaces:  for instance
VLANs.  One might argue that GRASP should only run on physical (untagged)
interfaces, but it is not uncommon in access networks for a single fat
(containing hundreds of tagged VLANs) pipe to come in a datacenter, and be
broken out by an external entity into physical connectors elsewhere, which
plug into equipment that should be part of the domain.

This is typically when purchasing lit fiber from an incumbent telco for instance.

    > Then when each bootstrap relay agent comes up it tells its local GRASP
    > engine that it's available to be discovered. In my prototype that would
    > use a function called grasp.register_obj(). Any device that wanted to
    > find a relay agent would ask its local GRASP engine using a function
    > called grasp.discover(). ACP engines would discover each other
    > similarly. What they do when they've found each other is out of scope
    > for GRASP.

In your context/mind, what is a "bootstrap relay agent"?

    > Clearly at that stage everybody is using non-ACP addresses (link-local
    > mainly) until the bootstrap phase is over and the ACP is established.

    > Does this make any sense?

Yes.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Nov 2015 16:38:24 +1300

> Those are not the same thing.

True, but in both cases GRASP will say "Oh, no security here" and refuse
to do much of anything except discovery. There are definitely details
to be defined here, of course.

> And for #2, this condition can persist on a per-interface basis for a long time.

Yes, but I assume that a device with multiple interfaces will maintain
per-interface status and per-adjacency status (see Michael B's adjacency
table for the ACP).

> their own CPE, or back again.

Yes. The ACP will have to monitor interfaces and adjacencies continuously for
that reason, and will thereby reveal its existence. GRASP discovery
traffic will reveal GRASP's existence. But we need to ensure that valuable
content is only sent on a secure channel.

> This is typically when purchasing lit fiber from an incumbent telco for instance.

Yes, I don't see how we can restrict it to physical interfaces.

> In your context/mind, what is a "bootstrap relay agent"?

It's labelled "Proxy" at https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-01#page-6

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Nov 2015 16:24:22 -0500

> True, but in both cases GRASP will say "Oh, no security here" and
    > refuse to do much of anything except discovery. There are definitely
    > details to be defined here, of course.

During the period that bootstrap is occuring, after a bootstrap relay agent
has been discovered, running GRASP on any interface is not, I think
desireable.   The reason is mostly concern for some kind of DoS or
initial-configuration vulnerability. (remember: "FIELD"/"SUPPORT" stuff in VMS?)

Should bootstrap fail, enabling it again to find a different bootstrap relay
*is* desireable.

    > per-interface status and per-adjacency status (see Michael B's
    > adjacency table for the ACP).

Yes, exactly.  I'm think that once bootstraped, the bootstrap relay agent ASA
would then want to *respond* on that interface.

    >> interface, need to think hard about what GRASP might reveal from a
    >> privacy point of view.  Some interfaces may *never* be used for the
    >> ACP, they could be customer facing, etc.  Yet, we need to periodically
    >> see if as a result of some cables being re-arranged, there is now a
    >> machine that *is* part of the domain.  An example here would be where
    >> an ISP's switches from using the ISP provided CPE to their own CPE, or
    >> back again.

    > Yes. The ACP will have to monitor interfaces and adjacencies
    > continuously for that reason, and will thereby reveal its
    > existence. GRASP discovery traffic will reveal GRASP's existence. But
    > we need to ensure that valuable content is only sent on a secure
    > channel.

This is partly why I think that a multicast IKEv2 INIT might be easier.

I understand that some people want to hedge their bets with building the ACP
using IKEv2, but we make everything configurable, I'd like to see some clear
use case.

    >> We also need to consider if/how we run on virtual interfaces: for
    >> instance VLANs.  One might argue that GRASP should only run on
    >> physical (untagged) interfaces, but it is not uncommon in access
    >> networks for a single fat (containing hundreds of tagged VLANs) pipe
    >> to come in a datacenter, and be broken out by an external entity into
    >> physical connectors elsewhere, which plug into equipment that should
    >> be part of the domain.
    >>

    > Yes, I don't see how we can restrict it to physical interfaces.

I believe that we will have to have some documented heuristics: we want ACPs
to come up wherever feasible, but we don't want to annoy ASAs with hundreds
to thousands of virtual interfaces which can never have an ACP.

You will have noticed when configuring your multicast socket, that you don't
have to create a socket per-interface, but can get the interface ifIndex out
along with each packet that you receive.  So listening to multicasts on
thousands of interfaces doesn't have to be very expensive in terms of program state.
(Except, as it turns out, with GRE interfaces on Linux, which do not return
their ifIndex, which seem to have a bug in this fashion, which I hope to fix)

As such, we may want to have
interfaces which are in four states:
           0) insecure GRASP announcements
           1) interface being used for bootstrap, suppress
           2) listen for insecure GRASP queries only
           3) ACP up on this interface, skeptically listen.

[when the ACP is up, it is likely that there is another interface to listen
to, but one has to continue listening because new devices could show up and
want to bootstrap, or the ACP could fail]

    > It's labelled "Proxy" at
    > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-01#page-6

Ah, okay!

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Dec 2015 16:44:33 +1300

> initial-configuration vulnerability. (remember: "FIELD"/"SUPPORT" stuff in VMS?)

That suggests to me that in addition to a flag saying "ACP is up", we need
another one saying "Security boostrap OK". Exactly what we make
conditional on that flag is a bit implementation-dependent.

> to thousands of virtual interfaces which can never have an ACP.

Again, that seems to be an implementation issue. I think it will be GRASP
that's annoyed; it should build a single queue of requests for each
ASA.

> along with each packet that you receive.  

Only with the Advanced Socket API, if I'm not mistaken. Python doesn't have that
in a form that works for Python 3.4. I have got a work around for now. Anyway,
that shouldn't matter for the design.

> So listening to multicasts on

Something like that, which is why I suggested a "Security boostrap OK"
flag.

    Brian