> On Apr 5, 2017, at 9:31 PM, Joe Touch <[email protected]> wrote:
>
>
>
> 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.
Okay, got it; socket options don’t exist in RFC 793 language, or any of the
RFCs updating it, I think…
maybe this RFC should have invented such a function call? Anyway, I can do
this for you :-) to some degree, that’s the role of my draft. I can say that
RFC 5925 demands this functionality, and describe SET_AUTH and GET_AUTH
primitives that would map to that.
>>> 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.
Okay…
>>> 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.
There isn’t much; Nagle is an example - RFC 1122 just says that the
functionality to enable / disable must be there, without specifying via which
primitive that would happen.
So, my draft says, in pass 2:
o DISABLE_NAGLE.TCP:
Pass 1 primitive / event: not specified
Seems like I should do the same for set_auth and get_auth.
Cheers,
Michael
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
