Subject: Re: [Anima-signaling] GRASP issue 52: Insecure instance text

From: Toerless Eckert <[email-masked]>
Date: Mon, 1 Aug 2016 02:29:07 -0700

Maybe Max has more details, he did take some notes.

>From my side:

- Define different "Modes" of GRASP, where each Mode has
  specific limitation (or none). Every Instance of GRASP has a particular Mode:

   DULL - Discovery Unsolicited Link Local

     This is the "insecure" mode, aka: Only Unsolicited Link Local Discovery Response
     Messages are permitted. Loop Count = 1. No redirects are permitted.

     (i don't think we need to constrain the announcements further to only bootstrap
      proxy etc. This should be nicely reuseable for any similar announcements, not
      only bootstrap proxy).
  
   FULL - Instance inside ACP. No restrictions.

   SONN - Secure Only Neighbor Negotiation 
      For use when negotiating (securely) an ACP channgel:
      loopcount=1 only. All messages permitted. 

Cheers
    Toerless

On Mon, Aug 01, 2016 at 09:01:56AM +1200, Brian E Carpenter wrote:
> Hi,
> 
> Here's another issue for design team comments.
> 
> I have a specific request from the bootstrap team to described in detail
> what is allowed and disallowed in an insecure instance of GRASP. The idea is
> that during bootstrap a separate instance of GRASP will run in its own memory
> space, such that it cannot contaminate the normal secure instance. For example
> it will have its own discovery cache. I will work on the text as soon as
> possible, based on some input from Max Pritikin. Any input welcome.
> 
> Regards
>    Brian
> 
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Aug 2016 14:26:51 +1200

>       loopcount=1 only. All messages permitted. 

Does that really need to be a separate instance? It can be controlled
completely via the API.

Regards
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Aug 2016 04:54:36 -0700

> Does that really need to be a separate instance? It can be controlled

How ? How would i inhibit that anything but the ACP-negotiation (TBD) objective
is going to be offered ? Lets assume inside the ACP the nodes do have
a bunch of other objectives they offer.

Also: Assume i have between two ACP nodes two parallel links, and the nodes
do have on both links the same link-local IPv6 addresses. For Objectives
of the ACP instnce of GRASP i do not care about those link-local addresses,
all ACP objectives should be bound to the routeable ULA off the AN node.
But when setting up the ACP in parallel across both links, then that has
to use the link-local addresses. Which would be overlapping.

This problem is solved for free when we define those ACP setup GRASP to be
separate instances on every interface in the same way as the DULL (insecure)
instances are.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Aug 2016 08:52:22 +1200

> a bunch of other objectives they offer.

When do you expect to use this instance? Only when a node initially joins
the ACP, or at any time (e.g. if a new link comes up)?

> to use the link-local addresses. Which would be overlapping.

Well, they should always be distinguished by the interface ID; that is always
available in the socket interface*. So I think you can have one instance that
handles all interfaces.

*However, the way you discover it is different in Posix and Winsock.

> separate instances on every interface in the same way as the DULL (insecure)

Well, you still need to discover which interfaces you have, before you create
those instances. So I'm not convinced there is any benefit in one instance
per interface.

Rgds,
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Aug 2016 14:42:02 +1200

OK, here is what I got from Max's notes and the discussion with
Toerless. This is a new section proposed for the GRASP spec. (It also
covers Issue 49.) Comments?

   Brian

3.3.2.  Limited Security Instances

   This section describes three cases where additional instances of
   GRASP are appropriate.

   1) As mentioned in Section 3.2, some GRASP operations might be
   performed across an administrative domain boundary by mutual
   agreement.  Such operations MUST be confined to a separate instance
   of GRASP with its own copy of all GRASP data structures.  Messages
   MUST be authenticated and SHOULD be encrypted.  TLS is RECOMMENDED
   for this purpose.

   2) During initialisation, before a node has joined the applicable
   trust infrastructure, [I-D.ietf-anima-bootstrapping-keyinfra], it is
   impossible to secure messages.  Thus, the security bootstrap process
   needs to use insecure GRASP discovery, response and flood messages.
   Such usage MUST be limited to link-local operations and MUST be
   confined to a separate insecure instance of GRASP with its own copy
   of all GRASP data structures.  This instance is nicknamed DULL -
   Discovery Unsolicited Link Local.

   The detailed rules for the DULL instance of GRASP are as follows:

   o  An initiator MUST only send Discovery or Flood Synchronization
      link-local multicast messages with a loop count of 1.  A
      responder MAY send a Discovery Response message. Other GRASP
      message types MUST NOT be sent.

   o  A responder MUST silently discard any message whose loop count is
      not 1.

   o  A responder MUST silently discard any message referring to a GRASP
      Objective that is not directly part of the bootstrap creation
      process.

   o  A responder MUST NOT relay any multicast messages.

   o  A Discovery Response MUST indicate a link-local address.

   o  A Discovery Response MUST NOT include a Divert option.

   o  A node MUST silently discard any message whose source address is
      not link-local.

   3) During ACP formation [I-D.ietf-anima-autonomic-control-plane], a
   separate instance of GRASP is used, with unicast messages secured by
   TLS, and with its own copy of all GRASP data structures.  This
   instance is nicknamed SONN - Secure Only Neighbor Negotiation.

   The detailed rules for the SONN instance of GRASP are as follows:

   o  Any type of GRASP message MAY be sent.

   o  An initiator MUST send any Discovery or Flood Synchronization
      link-local multicast messages with a loop count of 1.

   o  A responder MUST silently discard any Discovery or Flood
      Synchronization message whose loop count is not 1.

   o  A responder MUST silently discard any message referring to a GRASP
      Objective that is not directly part of the ACP creation process.

   o  A responder MUST NOT relay any multicast messages.

   o  A Discovery Response MUST indicate a link-local address.

   o  A Discovery Response MUST NOT include a Divert option.

   o  A node MUST silently discard any message whose source address is
      not link-local.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Aug 2016 10:44:07 +1200

Oops, I'm not sure Max will have seen this. Waiting for comments.

    Brian

-------- Forwarded Message --------
Subject: Re: [Anima-signaling] GRASP issue 52: Insecure instance text
Date: Wed, 3 Aug 2016 14:42:02 +1200
From: Brian E Carpenter <[email-masked]>
Organization: University of Auckland
To: Toerless Eckert <[email-masked]>
CC: Anima signaling DT <[email-masked]>

   Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 17 Aug 2016 22:49:36 +0000

> On Aug 17, 2016, at 4:44 PM, Brian E Carpenter <[email-masked]> wrote:
> 

thanks for the heads up Brian. I’ll look at this later this evening or tomorrow morning. Unable to get to it just now,
- max