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

[Brian E Carpenter <[e-mail]>]

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 <[e-mail]>
Organization: University of Auckland
To: Toerless Eckert <[e-mail]>
CC: Anima signaling DT <[e-mail]>

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.