On Sat, Jun 03, 2017 at 01:28:03PM +1200, Brian E Carpenter wrote: > On 03/06/2017 01:22, Toerless Eckert wrote: > > Dear authors: > > > > P1: 3.8.4: > > " In a more complex implementation, the GRASP discovery mechanism will > > find, > > for each interface, a dynamic port that it can bind to for both UDP and > > TCP > > before initiating any discovery. " > > > > AFAIK currently, there is no definition of an originator port in > > the discovery message (initiator = ipv* address), so i can not see > > how the above mentioned "more complex implementation" could work. How > > would the responder know the dynamically assigned TCP or UDP port of the > > initiator ? > > It's available in the socket API, returned with the message by recvfrom(). > > > How would it know whether to respond via TCP or UDP ? > > It's specified as always TCP. The phrasing is confusing though; we need to > find a port that is available for *sending* UDP and *listening* for TCP. > Will rephrase.
So, in the first place, the question is why anyone would want to have "a more complex implementation". The text does not answer this question but should answer it. I guess the reason would go back to what we discussed long ago wrt. how much GRASP an ASA wants to do itself vs. how much some shared GRASP daemon/ASA needs to do. With what you write about a complex implementation, it _might_ be possible to do more GRASP in the client ASA and minimize code in a shared GRASP daemon: 1. Responder ANI device has 5 ASA. Each ASA is its own process, binds to it's own TCP port. That same port number must also be available as a free UDP port. 2. Responder ASA1 registers an objective with the GRASP ASA/Daemon. GRASP ASA/Daemon is the one listening to GRASP Discovery messages on the GRASP multicast address and GRASP port. This is the "shared daemon" requirement because we can't be certain all OS's support replicating received multicast messages to multiple sockets from different processes. 3. Now Initiator ASA on a different device wants to discover that responder ASA1 objective and wants to make sure that the TCP connection built can be directly from the responder ASA1 to the initiator ASA - without the need to pass traffic of that GRASP TCP connecetion via the GRASP daemons: 4. So, initiator ASA tries to find a port that it can bind to for both TCP and UDP. Once it has found that port, it will send a UDP multicast GRASP discovery to the GRASP destination port and with the source port being its own bound UDP port. 5. Now the responder ANI devices GRASP daemon receives that discover message. because that objective was registered by ASA1, the GRASP daemon passes the discovery request to ASA1 including the UDP source port from the received discovery message. 6. Now the ASA1 on the responder can build a TCP connetion back to the initiator using the same TCP port as UDP port. http://www.staples.com/Staples-Easy-Button/product_606396 (highly recommended product when dealing with obfuscated technology !) So... IMHO that problem of dealing with multicast and socket API issues is already difficult enough without having to deal with the problem of having to be able to bind to the same port number for UDP and TCP: IMHO, the discover multicast message needs to have another message element which is the port number to reply to. Thats assuming the reply is always TCP. If you feel UDP should also be an option then the discovery message should indicate the desired reply mode UDP/TCP and port number. Now, both approaches have a normal socket API security issue: when the responder receives the discovery message and in return builds a TCP connection, there is no guarantee that the actual TCP port on the initiator is owned by te same process as the UDP port in the discovery - whether its in the UDP source port field of the discovery message or in a GRASP message element. So, if we want to secure this UDP multicast discovery -> TCP reply in the context of existing socket APIs, then i think the mechanism could be further refined: In the context of standard socket APIs, a responder can not know for certain that the initiator TCP port is owned by the process that initiated the discovery request. The only mitigation is to a) trust the GRASP daemon on the remote side. b) The remote GRASP daemon has bound to the GRASP UDP port, so discovery multicast packets whose source UDP port is also the gRASP port (the destination port must be the GRASP port) are trusted to have come from the remote GRASP daemon. And then the TCP port number in the discover message is trusted. c) GRASP daemons can use local mechanisms to ensure that the TCP port indicated by an ASA is also owned by the ASA (aka: the interface between an ASA daemon and a GRASP daemon can use a POSIX standard UNIX socket and the gRASP daemon creates that socket and passes it back to the ASA). That way the GRASP daemon knows the TCP socket port number reliably. This is all convoluted. If you are not a big fan of concoluted explanatory text like what i wrote up above, i can understand it. But i am not a big fan of suggestive incomplete text that you have on the draft right now... The text optimized version of this is: a) add the (TCP) port parameter into the discovery message and remove text about "complex implementations" ;-) (and put the discussion into the guidelines document as you suggested below). > > P2: > > > > In draft-ietf-anima-prefix-management, two GRASP objective-names(s) are > > PrefixManager and PrefixManager.Params. Looks as if its useful to think of > > the > > objective-name space as hierarchical. But i do not find any text to that end > > in the GRASP draft. I would love to see GRASP objective-names to have at > > least for the purpose of IANA registration at least one level of hierarchy, > > which is <word1>(.<wordI>)* and that IANA registrations are only for word1. > > Otherwise we would end up with a lot more "surplus"? IANA registrations that > > really only are details of a particular ASA/autonomic-function. > > Personal opinion: You may be right, but I'm not sure yet. Can we leave > this for an update? It seems quite easy to retro-fit this to the registry > when we have experience. For now, it will just give the IESG something > else to DISCUSS. Sure. If that ever requires a one page follow-on RFC to change registry semantic from name to name-prefix, count me in as an author ;-P > > P3: 3.8.11 Flood Synchronization Message [...] > > GRASP has no mechanism to flush long lived objectives whose announcer has > > died. > > True, but that's a feature. If we've announced (say) the URL for Intent and > the > announcer dies, it doesn't mean the Intent is dead. Right, but if we are a registrar and die then the proxies can not use us anymore. Which can be solved by failing connections etc. pp.. > > > ASA that use M_FLOOD objectives should primarily rely on transport layer > > mechanisms > > to determine the aliveness of a specific locator of such an objective: > > determine > > that an objective locator has become inoperatble due to "unreachable" > > signaling > > (eg: ICMP) or timeouts in attempts to establish a connection. Announcers of > > M_FLOOD > > objectives should carefully consider the time-to-live for such objectives > > to avoid > > that stale entries clog up caches and force a large number of clients to > > probe > > (unsuccessfully) a failed objective locator. For an objective with few > > locators > > in the network, a periodicity of 30 seconds and time-to-live of 90 seconds > > may be > > a good compromise (Supporting loss of as much as 3 out of three M_FLOOD > > messages). > > be lost. Note that every periodic announcement needs to have a new > > session-id to > > ensure that he new periodic messages is not ignored by GRASPs duplicate > > elimination > > mechanism. > > That's about right I think, but do we want to say this in the protocol spec? > I don't think we want to give the IESG any new text to chew on right now. > I'll take it as good input to draft-carpenter-anima-asa-guidelines Sure. Do you mind an informational forward pointer to that doc in the GRASP spec so as to leave that breadcrumb ? > > P4: > > > > " If a subsequent Flood Synchronization message carrying the same objective > > arrives with a different tag, a new cached entry MUST be created" > > > > I think this should not say "objective", but "objective-name". Eg: consider > > that any of the parameters of the objective have changed, then the new > > entry should > > also overwrite the old entry (for the same locator). > > Yes, that's the intention. If the name and tag are the same, it overwrites. > We can make it clearer. To me, "same objective" means "objectve with the > same name" but I can see it might be unclear. I have started to use the names as they are defined in CDDL ;-) > > More fundamentally: The orinator of M_FLOOD objectives would periodically > > send the M_FLOOD and the content of the new M_FLOOD would simply > > overwrite/refresh > > the cache content for what was cached with the same tag. Aka: that > > explanation > > should be rewritten. One could argue that it gets overwritten because the > > new > > M_FLOOD with its fresh time-to-live will have a longer lifetime than the > > cache > > entry, but event hat is IMHO to complex. The rule should simply be to > > update > > cache entries with fresh M_FLOOD information received (and just ignore > > duplicates > > with sesion-id). > > Iy seems to me that the previous sentence ending "the corresponding cached > copy > of the objective MUST be overwritten" says this quite clearly. If it wold say objective-name, yes. My implied question was if he method of "dying-gasp" should work: eg: a graceful removed objective could announce itself with M_FLOOD of time-to-live = 1 sec and therefore overwrite any further longer-lived ttl. I think it should work, but given how terse the text is, i wonder if implementations would do the right thing (yeah, i k ow 78 pages and still this toerless guy calls it terse ;-) I like the guidelines draft option of outsourcing additional explanatory text. > > P5: > > > > 6. CDDL Specification of GRASP > > "objective-name = text ;see specification for uniqueness rules" > > ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ > > Which specification (i thought this is the specification), > > which uniqueness rules ? (uniqueness does not otherwise occur in the doc). > > Section <mumble>. It's impossible to include an <xref> in CDATA text. > Will find a way to fix this. Yes, i stumbled across that problem in the bootstrap draft as well. Maybe just refer to the section with the picture. > > P6: The handling of locators in GRASP is somewhat confusing: Except when > > using the > > URI locator, there seems to be no consistent encoding in GRASP what > > protocol to > > use on top of a O_IPv6/v6_LOCATOR. Instead, the protocol to use is randonly > > encoded in the *any part of an objective. > > No. When you discover an objective, the discovered locator is [address, > protocol, port]. > Then there's an option on a flood to tag the flooded objective with [address, > protocol, port]. > I just don't see the problem. I am talking about the protocol inside of the UDP/TCP locator. > > And i could not even find text that > > describes this. Not sure where, but maybe add an explanation like the > > following: > > > > GRASP does maintain the notion of locators only to the extend necessary to > > ensure > > that different ASA can be implemented as different application (processes). > > In the > > context of typical operating systems, different application processes > > require > > different transport sockets, eg: (address,proto,port) sockets (as in > > O_IPV4_LOCATOR, > > O_IPv6_LOCATOR and indirectly O_FQDN_LOCATOR). GRASP does not standardize > > declarations > > about what protocols an ASA expects to be used across these locators. If > > ASA > > need to indicate/negotiate a specific protocol across such a locator then > > that > > protocol would need to be specified as part of the objective specific > > parameters. > > That's wrong, sorry. Of course you could put anything you like in the > objective value, > but GRASP already supplies the locator 3tuple. See your own example for BRSKI with GRASP in the ani recommendation draft. What you call method = BRSKI-TLS is what i call the protocol > > section 3.9.5: "GRASP is not intended to work across disjoint addressing or > > naming realms". > > > > a) It would be helpful to have corollary text such as this> > > When GRASP is run in the ACP context, > > this means that all locators indicate an ACP IPv6 address (O_IPV6_LOCATOR). > > Using > > O_FQDN_LOCATOR or O_URI_LOCATOR in the ACP context is safest if all > > IPv6 addresses of the domain name indicated are ACP addresses. ASA might > > also be > > able to identify IPv6 addresses to be part of the ACP because of their > > prefix, > > but that would be additional processing complexity not necessary when simply > > sticking to O_IPV6_LOCATORS of only ACP addresses. > > > > b) Another corollary that IMHO would be highly useful: > > > > The fact that GRASP is not intended to work across disjoint addressing > > spaces > > does not prohibit it to be used to signal and negotiate different address > > spaces: > > Consider a flood-message (M_FLOOD) in the context of running GRASP across > > the ACP: > > The objective independent locator option indicates a locator for the > > objective > > in the ACP. If there are locators for the objective outside of the ACP, > > then > > that locator would have to be encoded into the objective parameters - and > > it would > > be a problem for the involved ASAs to ensure that the receiving ASA will > > know > > what addressing/naming realm is indicated - and most likely that those ASA > > have > > connectivity to that addressing/naming realm. > > Look, I'm not very interested in adding yet more text to confuse the IESG > further. I think both of your comments are true but do you really want another > month of discussion? see below. > > > c) It would be nice if the CDDL for "objective" would not only say 'any', > > but > > would be given a name that we can use to refer to it, eg: > > 'objective-parameters' > > or 'objective-data' or the like. I like objective-parameters. > > But then we'd have a rule objective-parameters = any. Is that really > an improvement? Without that line we do not have a normative word for the parameters of GRASP objectives. For example, the whole discussion about name spaces could be one simple corollary: All locators used outside of grasp-parameters MUST be from the namespace GRASP is running in. Cheers Toerless > Regards > Brian > > > > > Cheers > > toerlss _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
