I'm sorry for the wide-ranging comments here; I started on Sunday on the airplane, but didn't finish until today. We talked M_FLOOD yesterday at the bootstrap call, and we will edit to synchronize with my comments here.
Chairs: Are we using the issue tracker? It's not in the menu at: https://tools.ietf.org/wg/anima/ If not, where did the issue # that Brian and co. used to track my previous comments? Oh, it's just numbers in the issues part of the document... I went through my previous comments which are at: https://www.ietf.org/mail-archive/web/anima/current/msg02148.html I think that sections 3.3 and 3.4 are a response to my request for an operating overview, and I think that this works well. I asked for examples, and they are in Appendix D, but while reading the document, I had forgot about it, and nothing told me to go look there in the text. A see D.1 would be good. Could I ask for small change: from: The initiator multicasts a discovery message: to: The initiator (2001:db8:f000:baaa:28cc:dc4c:9703:6781) multicasts a discovery message: [1, 13948744, h'20010db8f000baaa28ccdc4c97036781', ["EX1", 2, 2, 0]] and ditto for "A peer (X) responds", as it took me a minute or two to figure out what this third argument was, that it was the initiator address. Now to comments on the -08 text... 2.1 --- does this belong in GRASP, vs reference model document? Would like MB and Toerless to confirm that it is consistent in wording with reference model document! > D8. The discovery process must not generate excessive traffic and > must take account of sleeping nodes in the case of a constrained-node > network [RFC7228]. I think this actually out of charter, and furthermore, GRASP doesn't do a very good job of taking this into account. I think it should be striked out. SN7. orig: o Dependencies and conflicts: In order to decide a configuration on a given device, the device may need information from neighbors. orig: o Dependencies and conflicts: In order to decide upon a configuration for a given device, the device may need information from neighbors. > be as automatic as possible. The protocol's role is limited to > the ability to handle discovery, synchronization and negotiation > at any time, in case an ASA detects an anomaly such as a > negotiation counterpart failing. I think this sentence could use some work. Maybe: The protocol's role is limited to discovery, synchronization and negotiation. This process can occur at any time, and an ASA may need to repeat any of these steps when the ASA detects an anomaly such as a negotiation counterpart failing. 3.1. terminology was: Discovery, Negotiation and Synchronization. In the protocol, an objective is represented by an identifier and if relevant a value. new: Discovery, Negotiation and Synchronization. In the protocol, an objective is represented by an identifier and -- if relevant -- a value. (or maybe two comma are more correct) There is too much functional description in the XYZ Objective descriptions. At least, it needs to have a forward reference. going on, remove *cut*/*tuc* o Discovery Responder: a peer that either contains an ASA supporting the discovery objective indicated by the discovery initiator, or caches the locator(s) of the ASA(s) supporting the objective. *cut*The locator(s) are indicated in a Discovery Response, which is normally sent by the protocol kernel, as described later.*tuc* 3.2: >Interface (API) will be needed between GRASP and the ASAs. In some >implementations, ASAs would run in user space with a GRASP library >providing the API, and this library would in turn communicate via >system calls with core GRASP functions running in kernel mode. For I still don't know why "kernel mode" is used here. Certainly on Linux and Windows, we don't need code in the "kernel", just a priviledged process if we are allocated a <1024 port, otherwise, just an unprivledged system daemon. On a Cisco/Huawei/Broacade router, I don't know a lot about OS architecture, but on Juniper a straight FreeBSD process would work fine. "operating system core module" (section 3.4) is much better. I think I mentioned "kernel" issue before. The reference to RFC2608 seems unwaranteed on page 13. section 3.3 was good to write down, but seems like it is too much like a discussion. I would like the bullets as subsections, as they are really modes of operation! 3.4 should mention M_FLOOD along with M_DISCOVERY. or, perhaps the M_FLOOD mechanism can be clearly labelled as providing awareness of an ASA. I appreciate 3.5.1 trying to establish some security via (D)TLS, but it simply doesn't say enough to result in interoperability. (for instance, should certificates be validated? If so, what should be in the CN? Do we need PFS? When do we rekey? Are client-side certificates important? Is there a link between IP addresses and something in the CN?) I'd prefer that all the mention of TLS be removed to another document that would specify it more completely, a document titled something like: "Using GRASP between service providers" or: "Securing GRASP using TLS" or: "CoAP/DTLS mode for GRASP" I'd like 3.5.2 point (1) be numbered 3.5.2.1 so it can be better referenced, and I'd like it say something like: 3.5.2.1 Inter-domain GRASP Instance As mentioned in Section 3.3, some GRASP operations might be performed across an administrative domain boundary by mutual agreement. Such operations MUST be confined to a separate instance of GRASP with its own copy of all GRASP data structures. Details of this mode are the subject of a future document that would clearly detail the security limitations of such an instance. 3.5.2.2 Bootstrap and ACP GRASP Instance (DULL) This instance is nicknamed DULL - Discovery Unsolicited Link Local. The bootstrap process uses only M_FLOOD messages to announce the location of the bootstrap proxy. This message is used only on-link using link-local multicast, on the underlying (insecure) media. Full ANIMA nodes that act are willing to act as bootstrap proxies will include a flag indicating this into this message. Full ANIMA nodes looking for ACP peers will also indicate that in the message. Full ANIMA nodes MAY listen for M_FLOOD messages on insecure interfaces. Other messages MUST be discarded. M_FLOOD messages which are improperly formatted such as: o having a loop count > 1 o having a GRASP message type != M_FLOOD o having a non-link-local source address MUST be discarded. It is acceptable for the M_FLOOD to be to the ALL_GRASP_NEIGHBOR multicast address, or to be unicast to the host in question. ANIMA nodes in bootstrap mode listen on the ALL_GRASP_NEIGHBOR multicast address, and listen according to the same rules above, but examine the BOOTSTRAP_PROXY attribute only. Details of DULL are included in: [I-D.ietf-anima-autonomic-control-plane] I want to suggest that point (3), about ACP formation be dropped, as it is included in part 2. In 3.5.3, please delete: In particular, to guarantee interoperability during bootstrap and startup, using TCP for discovery responses is strongly advised. I don't think it makes any sense at this point. Bootstrap discovery will use M_FLOOD, while actual bootstrap uses either EST (RFC7030) which is HTTP/TCP, or possibly one of the EST over CoAP proposal(s) [yes, currently plural, alas] Again, please omit further discussion of TLS. In section 3.5.4.1, can we write: The discovery (M_DISCOVERY) action will normally be followed by a negotiation (M_REQ_NEG) or synchronization (M_REQ_SYN) action. The discovery results could be utilized by the negotiation protocol to decide which ASA the initiator will negotiate with. 3.5.4.2: A complete discovery process will start with a multicast (of M_DISCOVERY) on the local link. On-link neighbors supporting the discovery objective will respond directly (with M_DISCOVERY). A neighbor with multiple interfaces SHOULD respond with a cached discovery response if it was learnt from another interface. ADD: A neighbor SHOULD NOT respond with a cached response on an interface if it learnt that information from the same interface. 3.5.4.3: s/GRASP kernel/GRASP core/ 3.5.4.4: QUERY re: 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 (see Section 3.8.4). I thought we were adding something about Link Local addresses here? 3.5.5: re: The details, including the distinction between dry run and an actual configuration change, will be defined separately for each type of negotiation objective. I would very much like it if dry-run/real-run request was standardized. This would make external auditing/debugging (such as via network sniffer) much easier to see. Can we change this paragraph to include message types? If the counterpart can immediately apply the requested configuration, it will give an immediate positive (accept) answer (using M_END). This will end the negotiation phase immediately. Otherwise, it will negotiate (using M_NEGOTIATE) It will reply with a proposed alternative configuration that it can apply (typically, a configuration that uses fewer resources than requested by the negotiation initiator). This will start a bi- directional negotiation (using M_NEGOTIATE) to reach a compromise between the two ASAs. ... a peer to insert latency in a negotiation process if necessary (Section 3.8.9, M_WAIT). 3.5.5.1: change: A Discovery message MAY include a Negotiation Objective option. In this case the Discovery message also acts as a Request Negotiation message to indicate to the Discovery Responder that it could directly reply to the Discovery Initiator with a Negotiation message for rapid processing, if it could act as the corresponding negotiation counterpart. However, the indication is only advisory not prescriptive. to: A Discovery message MAY include a Negotiation Objective option. In this case it is as if the initiator sent the sequence M_DISCOVERY, followed by M_REQ_NEG. This has implications for the construction of the GRASP core, as it must carefully pass the contents of the Negotiation Objective option to the ASA so that it may evaluate the objective directly. When a Negotiation Objective option is present the ASA replies with an M_NEGOTIATE message (or M_END if it is immediately satisfied with the proposal), rather than with an M_RESPONSE. 3.5.6.1: s/GRASP kernel/GRASP core/ Please add, after para 4, ("..with multiple link-layer.."): Link-Layer Flooding is supported by GRASP by setting the loop count to 1, and sending with a link-layer source address. Floods with link-layer source addresses and a loop count larger than 1 are not supported, and such messages MUST be discarded. My comments about section 3.5.5.1 would seem to apply to 3.5.6.2 as well. 3.8.3: please add: The CBOR parser used by GRASP should be configured to know about the GRASP_DEF_MAX_SIZE so that it may defend against overly long messages. 3.8.4: Exceptionally, a Discovery message MAY be sent unicast to a peer node (via UDP or TCP), which will then proceed exactly as if the message had been multicast, except that when TCP is used, the response will be on the same socket as the query. 3.8.6, about: > If a node receives a Request message for an objective for which no > ASA is currently listening, it MUST immediately close the relevant > socket to indicate this to the initiator. if the time sequence is: initiator ----M_DISCOVERY---> responder (GRASP core) (UDP) ...> pass details to ASA initiator<----M_RESPONSE----- ASA (TCP) initiator-----M_REQ_NEG-----> ASA (same socket) then, according to above, why would an ASA have responded in the first place if not be the right ASA? 3.8.11: I think that the "initiator" option is just an IP address. No port number or protocol (UDP/TCP), right? Can we please have an example for M_FLOOD? Is this valid: [M_FLOOD, 124567, fe80::1234, 27, [[O_IPv6_LOCATOR, fe80::1234, IPPROTO_UDP, 500]], ["ACP", flags, 1, ["bootstrap-okay"]] Could an O_DIVERT occur in an M_FLOOD? Can we have more than one locator option? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima