Subject: Re: [Anima-signaling] Next step on GRASP draft - feedback please

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Dec 2016 08:40:11 +1300

Not hearing any negative comments, I will assume agreement on these three
points and edit the XML accordingly:

> 59.  Add F_NEG_DRY flag to specify a "dry run" objective?.
> 60.  Change M_FLOOD syntax to associate a locator with each objective?		 	      	
> 62.  Is it helpful to tag descriptive text with message names (M_DISCOVER etc.)?

Looking to see some discussion between Michael R and Toerless on

> 61.  Is the SONN constrained instance really needed? 

Regards
   Brian

On 29/11/2016 12:47, Brian E Carpenter wrote:
> Hi,
> 
> I've now gone through Michael's comments (see previous message).
> So there is a candidate -09 version at
> https://github.com/becarpenter/animaproto/commit/54877e
> and for convenient viewing, the diffs are temporarily at
> https://www.cs.auckland.ac.nz/~brian/Diff-draft-ietf-anima-grasp-08-09A.htm
> 
> At the moment I've included 4 open issues:
> 
> 59.  Add F_NEG_DRY flag to specify a "dry run" objective?.
> 60.  Change M_FLOOD syntax to associate a locator with each objective?		 	      	
> 61.  Is the SONN constrained instance really needed?
> 62.  Is it helpful to tag descriptive text with message names (M_DISCOVER etc.)?
> 
> My personal inclination is to say "yes" to #59, #61 and #62.
> 
> We really need Michael R & Toerless to reach an agreement about #61.
> 
> Input on the above and any other issues, please, please.
> 
> Regards
>    Brian
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Dec 2016 16:57:53 +1300

OK, I've been working on the other issues that I'm aware of
(including adding the dry-run flag - easy - and changing Flood
to associate a locator with each objective - very easy in the draft,
quite a lot of work in the prototype). So unless Michael's re-review
comes up with more, SONN is now the only open issue.

I looked at the text again just now and it's a fairly simple question:
If ACP formation can just use Flood as an announcment for ACP neighbors
to find each other and start IKEv2, I agree that we don't need SONN.

I'm also not at all clear how SONN would work. The text says it
will use TLS but I'm unclear where the certs would come from.

But you ACP folks have to chime in. Please. I'd really like us to
put a new version out to the WG very soon, otherwise we get into the
holidays.

Regards
   Brian

On 01/12/2016 15:33, Brian E Carpenter wrote:
> On 01/12/2016 13:34, Michael Richardson wrote:
>>
>> Brian E Carpenter <[email-masked]> wrote:
> (BTW, I meant #60 there.)
> 
>>
>> I think that I said we didn't need it.
> 
> You did. But Toerless proposed it, so we need his opinion.
> 
>> That all we need is to become aware of the neighbours (which insecure DULL
>> can do with M_FLOOD), and that all the security is best done by IKEv2.
>> (And IKEv2, even if MacSEC is negotiated rather than IPsec)
>>
>> The ACP-04 document imagines a protocol that isn't IKEv2 using some
>> unspecified encapsulation over (d)TLS transporting IP packets, and negotiated
>> using GRASP.  This hardly has any existing specification (one in tsvwg right
>> now), and has no hardware support anywhere.  It's not our place in this WG
>> to create new security protocols.
> 
> Yes, all I would expect to see negotiated over GRASP would be *which* security
> mechanism to use; that's what is assumed in
> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-00#section-3.2
> 
> I have no skin in the game though; I'm quite happy with
> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-00#section-3.1
> 
> Toerless?
> 
> Rgds
>    Brian
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Dec 2016 08:08:39 +1300

Hi,

We need to move ahead with the GRASP draft. Therefore, I have reworked the
text in a way that doesn't remove the SONN description but does not make
it a requirement either. Please comment on the new version of the whole
section that follows. I'm going to take silence as consent 48 hours from now.

Regards
   Brian

3.5.2.  Constrained Instances

   This section describes some examples of cases where additional
   instances of GRASP subject to certain constraints are appropriate.

3.5.2.1.  No ACP

   As mentioned in Section 3.3, some GRASP operations might be performed
   across an administrative domain boundary by mutual agreement, without
   the benefit of an ACP.  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 [RFC5246] and DTLS [RFC6347] based on a Public Key Infrastructure
   (PKI) [RFC5280] are RECOMMENDED for this purpose.  Further details
   are out of scope for this document.

3.5.2.2.  Discovery Unsolicited Link-Local

   Some services may need to use insecure GRASP discovery, response and
   flood messages without being able to use pre-existing security
   associations.  Such operations being intrinsically insecure, they
   need to be confined to link-local use to minimise the risk of
   malicious actions.  Possible examples include discovery of candidate
   ACP neighbors [I-D.ietf-anima-autonomic-control-plane], discovery of
   bootstrap proxies [I-D.ietf-anima-bootstrapping-keyinfra] or perhaps
   initialisation services in networks using GRASP without being fully
   autonomic (e.g., no ACP).  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
      SHOULD NOT send a Discovery Response message unless it cannot be
      avoided.  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 a service that requires
      this insecure mode.

   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.

   GRASP traffic SHOULD be minimized by using only Flood Synchronization
   to announce objectives and their associated locators, rather than by
   using Discovery and Response.  Further details are out of scope for
   this document

3.5.2.3.  Secure Only Neighbor Negotiation

   Some services might use insecure on-link operations as in DULL, but
   also use unicast synchronization or negotiation operations protected
   by TLS.  A separate instance of GRASP is used, 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 service concerned.

   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.

   Further details, including TLS and PKI usage, are out of scope for
   this document.

--