Thanks Michael, we will wait a few more days before rolling up all comments received. I am fine with most of your suggestions. A few things caught my eye:
>> in the case of a constrained-node network [RFC7228]. Yes, that clause is out of scope. >> >system calls with core GRASP functions running in kernel mode. For ... > I still don't know why "kernel mode" is used here. You're correct, it's unnecessary. > The reference to RFC2608 seems unwaranteed on page 13. A matter of taste I guess. But it can be dropped with no pain. > I'd prefer that all the mention of TLS be removed to another document that > would specify it more completely, If we did that, we'd need at least to say that it's out of scope. I certainly agree that it's underspecified at the moment, which probably worse than saying nothing. > 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? What was the point there? (Clearly, discovered link-local addresses MUST NOT be sent on to another interface, is that it? But that affects the Discovery Response process, not the relay process. Must check my code, too...) > 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. Hmm. That needs some thought. I thought that the semantics of this was very hard to capture in a generic way. (One way would be to add a new flag value, so that an objective could be labelled F_NEG for negotiation and F_NEG_DRY for dry-run negotiation. That has a great advantage - it could be retrofitted any time, and can be rejected with an M_INVALID by a node without dry-run capability.) > 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? This covers the case where the ASA crashes at the critical moment - without this provision (depending on implementation details) the socket would be left hanging. Also consider that discovery results can be cached, so there might be a real time gap between the M_RESPONSE and the M_REQ_NEG, giving more chance that the ASA crashes or even exits cleanly. > 3.8.11: > I think that the "initiator" option is just an IP address. > No port number or protocol (UDP/TCP), right? Correct, as currently specified. It's only there to disambiguate the session ID in the minute chance of an ID collision. > 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"]] I think so, but I'll need to run it through my primitive validation chain... > Could an O_DIVERT occur in an M_FLOOD? Not in the current syntax, and I'm not sure why we'd need it. > Can we have more than one locator option? No. That is a feature - if you embed multiple objectives in a single M_FLOOD, they are all associated with the same locator option. If that's a problem, now would be a good time to say so ;-). Regards Brian On 24/11/2016 11:47, Michael Richardson wrote: > > 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 <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
