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

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

Thanks much Michael. Do you want to repeat this on the main Anima list
in response to the last call? Regardless, I will respond next week
(it's already Saturday here). Our Chinese colleagues are all off now
for their National Day holiday week.

Regards
   Brian

On 01/10/2016 06:15, Michael Richardson wrote:
> 
> 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 =-
> 
> 
> 
> 
> 
> _______________________________________________
> Anima-signaling mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-signaling
>