I was supposed to repost this to the main list, but didn't get to it. I realize that WGLC is over, but I wanted to make sure it was in the record.
--- Begin Message ---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: 184.108.40.206 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 <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
Description: PGP signature
--- End Message ---
-- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima