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

["Max Pritikin (pritikin)" <[e-mail]>]

> On Aug 17, 2016, at 4:44 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> Oops, I'm not sure Max will have seen this. Waiting for comments.

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


> 
>    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.