Subject: [Anima] Active issues in GRASP

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Aug 2016 17:02:01 +1200

Hi,

Here's a summary of the active open issues in GRASP following
IETF 96. Not all of these were listed in the -06 draft.

Comments please! It would be helpful to include the issue number in the Subject.

43.  Rapid mode synchronization and negotiation is currently
     limited to a single objective for simplicity of design and
     implementation.  A future consideration is to allow multiple
     objectives in rapid mode for greater efficiency.

==> Proposed resolution is to simply include this statement in the main text.

48.  Should the Appendix "Capability Analysis of Current
     Protocols" be deleted before RFC publication?

==> We got the message from the meeting that we should keep this.

49.  Section 3.3.1 should say more about signaling between two
     autonomic networks/domains.

==> Proposed resolution is to briefly describe a separate GRASP instance
    to allow this without risking the security of the normal GRASP instance.

50.  Is Rapid mode limited to on-link only?  What happens if first
     discovery responder does not support Rapid Mode?  (Section 3.3.4,
     Section 3.3.5)

==> This is somewhat complicated. The signaling design team will think
    about it, but WG input is very welcome.

51.  Should flooded objectives have a time-to-live before they are
     deleted from the flood cache?  And should they be tagged in the
     cache with their source locator?

==> Proposed resolution is to note that an objective could contain its own
    timestamp or refresh interval data. And yes, cached values should be
    tagged with their source.

52.  Describe in detail what is allowed and disallowed in an
     insecure instance of GRASP.

==> This is at the request of the secure bootstrap and ACP teams. Text
    will be proposed.

53.  Tune IANA Considerations to support early assignment request.

==> This is not hard, text will be proposed.

Regards
   Brian Carpenter
   Anima signaling design team

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 2 Aug 2016 13:16:33 -0400

It strikes me that if we wish to allow for inter-domain communication 
using GRASP, in conjunction with intra-domain usage, then the security 
considerations are more complex than noted so far.

I think this can be addressed by writing security considerations text 
that explicitly talks about the need to be careful about what 
information is exchanged between intra and inter-domain grasp instances, 
so as to avoid either leakage or contamination.
If this is done, then additional text in 3.3.1 could point to that to 
make sure that these limited instances are properly limited.

I do wonder, given the possibility of such information leakage, if there 
is an added complication of information being improperly attributed 
after such exchanges.  I would hope we can avoid a Grasp version of the 
famous cases of BGP information being injected into IGPs, and then 
re-exported as if it were locally sourced information.

Yours,
Joel

> Comments please! It would be helpful to include the issue number in the Subject.
...
>     to allow this without risking the security of the normal GRASP instance.
...

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Aug 2016 15:07:04 -0400

Joel M. Halpern <[email-masked]> wrote:
    > It strikes me that if we wish to allow for inter-domain communication using
    > GRASP, in conjunction with intra-domain usage, then the security

I agree strongly.

In particular, I would suggest that this really calls for a different
instance/profile of GRASP.  I.e. that routers should run a different context
(same as running OSPF in different VRFs), and that we should even consider
that it should do discovery on a different port.

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

---

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

> that it should do discovery on a different port.

I agree too. But there's an inevitable risk. One use case for this is a little
bit 'back to the future' - consider ASAs that act as bandwidth brokers. Network
A has a bandwidth broker. Network B has a bandwidth broker. They communicate
between domains using separate TLS-based GRASP instances. Faulty information
from A contaminates B's state, in complete security.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Aug 2016 21:38:35 -0400

Brian E Carpenter <[email-masked]> wrote:
    > I agree too. But there's an inevitable risk. One use case for this is a
    > little bit 'back to the future' - consider ASAs that act as bandwidth
    > brokers. Network

Sure.. but I'll bet that it's more reliable than the old-fashioned way of
picking up the telephone or the email, and say, "So, Bob, how much transit
did we buy again from you this week?"