Re: [Anima-signaling] comments on GRASP-07 draft

["Liubing (Leo)" <[e-mail]>]

Hi Michael,

Thanks a lot for your detailed review.
Since the GRASP-07 is under WGLC now, would you mind posting your below comment to the Anima mailing list as well?

Many thanks,
Bing

-----Original Message-----
From: Anima-signaling [mailto:[e-mail]] On Behalf Of Michael Richardson
Sent: Friday, September 30, 2016 7:16 PM
To: anima-signaling
Subject: [Anima-signaling] comments on GRASP-07 draft


I read draft-ietf-anima-grasp-07 from beginning to end.
This is probably my first read through in many months.
I will be happy to turn these into issues in the tracker if told to do so.

I am overall pleased with the document, it read well.

I did feel like there was a section missing between 2 and 3, that gives a detailed architecture use of GRASP, without resorting to bits on the wire.

I think that section 3.3 is trying to do this, but it failing because it gets into security before it has explained anything about how things work.
Maybe if 3.3.1/3.3.2 were moved to a new section 3.3b entitles "Protocol Security"
or some such.

I had to go learn about CDDL from  draft-greevenbosch-appsawg-cbor-cddl-08
(now -09), and then how it maps to bytes on the wire.

Can we please have some worked through examples with bytes on the wire?
I will attempt to contribute some.


Some specific text that I didn't like:

3.3.4,  Discovery Procedures section says:

         An exponential backoff SHOULD be
         used for subsequent repetitions, in order to mitigate possible
         denial of service attacks.

I agree that an exponential backoff SHOULD be used by senders in order to deal with overloads due to unintentional in corrolations of senders.
But, telling well-behaved senders what to do does nothing to mitigate denial of service attacks.  The point is that the malicious attackers are not well-behaved.

If the point is to tell responders that they should backoff in their replies, or rate limit their replies, then that would make sense, but since the reply will be by TCP (as I understand it), then the opportunity to do forged source address attacks is rather low.

Later in that section, it says:
         A GRASP device with multiple link-layer interfaces (typically a
         router) MUST support discovery on all interfaces.  If it
         receives a Discovery message on a given interface for a
         specific objective that it does not support and for which it
         has not previously cached a Discovery Responder, it MUST relay
         the query by re-issuing a Discovery message as a link-local
         multicast on its other interfaces.  The relayed discovery
         message MUST have the same Session ID as the incoming discovery
         message and MUST be tagged with the IP address of its original
         initiator.  Since the relay device is unaware of the timeout
         set by the original initiator it SHOULD set a timeout at least
         equal to GRASP_DEF_TIMEOUT milliseconds.


Could we rewrite this into positive language, and also split it up, and maybe
even number some of these things.   I suggest:

3.3.4.1     GRASP discovery relaying by routers

         A GRASP device with multiple link-layer interfaces (typically a
         router) MUST support discovery on all interfaces.

         Different interfaces may be at different security levels: each group
         of interfaces with the same security level SHOULD be serviced by the
         same GRASP process, except for Limited Security Instances which are
         always single-interface instances.

         When a router receives a Discovery message on any interface,
         for an objective that it supports, then acting like any other
         GRASP device, it replies to it.

         When a router receives a Discovery message for an objective that
         it does not support, but which for which it has previously cached
         a response, then it replies to that request with the cached
         information.

         When a router receives a Discovery message for an objective that
         it does not support, and for which it has no cached response, then
         it MUST relay the query by re-issuing a Discovery message as a link-local
         multicast on ALL of its other interfaces which are at the same
         security level as the incoming interface.

         The relayed discovery message formed MUST have the same Session ID
         as the incoming discovery message and MUST be tagged (XXX HOW?)
         with the IP address of its original initiator.  Since the relay
         device is unaware of the timeout set by the original initiator it
         SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT milliseconds.


section 3.7.3 says:
   The discovery initiator sends the Discovery messages via UDP to port
   GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBOR multicast
   address.  It then listens for unicast TCP responses on the same port,
   and stores the discovery results (including responding discovery
   objectives and corresponding unicast locators).


I have a problem with the mixing of UDP and TCP port numbers in this way.
First of all, this is text is ambiguous because the binding of "same" is unclear to me.  Let me number things so that the ambiguity is clear:
          sender:       UDP from: X  -> to: GRASP_LISTEN_PORT
          responder:    TCP from: Z  -> to: Y

  "then listens for unicast TCP responses on the same port"

could mean that         Y = GRASP_LISTEN_PORT,
or it could mean that   Y = X

Could we just *say* in the UDP which port the initiator is going to listen on?

Assuming Y=GRASP_LISTEN_PORT, may I suggest that if we say port '0' that it means grasp_listen_port, which is often GRASP_LISTEN_PORT, except if one
might be debugging,etc. when one might set it to another port.   That is, we
normally say, "0" to mean GRASP_LISTEN_PORT whatever it might be at that moment.  When we to reach at a port!="0", then we mean that port.

Y=X can be made to work if one picks X well, but may be unworkable on some platforms.

(I'm saying this mostly from experience with IKE, which originally said to ignore the source port of the UDP, and always use 500, which was a problem when it came to NAT traversal, but more to the point, it made it sometimes painful to test in-vitro).

I'm understanding that ONLY Discovery requests go out via UDP, but that all Discovery responses occur via TCP.  I'm a bit concerned about this process during bootstrap.  The Discovery initiator will have to be prepared for many TCP connections...  I guess we had assumed that the reply would be UDP as well.



--
Michael Richardson <[e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-