On 4/5/2017 12:12 PM, Michael Welzl wrote: > Hi, > > Thanks a lot for checking this! > > >> On Apr 5, 2017, at 8:01 PM, Joe Touch <[email protected]> wrote: >> >> >> >> On 4/5/2017 5:45 AM, Michael Welzl wrote: >>> This is the minor change that I promised at the last meeting - mainly to >>> include TCP Authentication (RFC 5925). >> There are bugs in the description. TCP-AO was careful to say "TCP SEND, >> or a sequence of commands resulting in a SEND" (same for RECEIVE), >> regarding setting or viewing received key IDs (current and next), > Hm, I saw this but didn’t get it - what is “a sequence of commands resulting > in a SEND” (or RECEIVE) ? > I just don’t get what that’s supposed to mean. E.g., what else than SEND will > send?
E.g., setting a socket option to set values then using SEND, or RECEIVE then socket options to read. The point was that the setting of those values can be asynchronous to the SEND/RECEIVE calls. > >> especially including ways to set/read these values even when a SEND or >> RECEIVE isn't issued (e.g., to affect retransmissions or ACKs). > I also saw this but didn’t see it as mandatory to provide (“It may be > useful…”, the text says). Is this really very useful? You might want/need to change keys on a BGP session even when you aren't yet ready to issue a SEND. You might want to check to see of the keys have changed due to retransmissions or ACKs even when you didn't issue a RECEIVE. > >> I didn't give a deep re-read and I don't recall from my earlier checks, >> but is there a discussion of using other operations to interact with >> connection parameters (socket options, ioctls), e.g., as part of the >> required interface? > Nothing that’s not in the RFCs… I did rephrase the authentication stuff for > TCP as “CONNECTION.MAINTENANCE” primitives (set_auth, get_auth), stating that > they’d be implemented using SEND and RECV. Not much else available… > > If you say it’s important it can be added, I guess, but I find it hard to > derive that from the text in RFC 5925. Well, empty send’s and receive’s are a > way out, I suppose. It's not just RFC 5925. The issue is whether there are other mandatory configurations or monitoring that is async to SEND/RECEIVE. If so, then you can't simply assume they occur only during those calls. Joe _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
