Subject: Re: [Tsvwg] [resend] sctpsocket-17 comments

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Nov 2008 21:42:07 +0100

Hi Vlad,

comments in-line.

Best regards
Michael

On Jul 21, 2008, at 4:53 PM, Vlad Yasevich wrote:

> [... fixed Randy's email.  resending, sorry for dups... ]
>
> Hi Michael, Randy
>
>> 6.3.1.11. SCTP_AUTHENTICATION_FREE_KEY_EVENT	
>> 				
>> 	When SCTP-AUTH wik not use a key identifier for sending packets	
>> 	anymore, this notification is provided by the kernel to the user.
>
> s/wik/will
Fixed in CVS.
>
>
> Also, shouldn't this event be generated when the key is actually  
> removed
> from the list of keys the kernel knows about, and not when the key  
> deactivated?
> (this is jumping ahead as I have questions about deactivation)
The scheme is a follows:
1. The application uses adds a key.
    From now on it can be used for processing received packets.
2. The application makes the key the active.
    From now on the kernel uses this key for sending user messages
    provided after this operation.
3. The application deactivates the key.
    From now on the application will not use key anymore. When the  
kernel
    does not need it anymore (for queued DATA transmission/ 
retransmissions)
    the kernel provides a SCTP_AUTH_FREE_KEY event.
4. The user can delete the key.
>
>
>
>> 8.1.21. Get or set the active shared key (SCTP_AUTH_ACTIVE_KEY)	
> ...
>> 	When used with setsockopt() the SCTP implementation MUST use the	
>> 	indicated shared key identifier for all messages being sent after	
>> 	the setsockopt() call until changed again. Therefore the SCTP	
>> 	implementation MUST NOT bundle user messages which should be	
>> 	authenticated using different shared key identifiers.
>
> Hmm..  so someone can now do:
> 	setsockopt(...) /* key 1 */
> 	sendmsg(...)
> 	setsockopt(...) /* key 2 */
> 	sendmsg(...)
>
> The two can't be bundled, even if Nagle is turned on or something  
> needs to
> be retransmitted?
Correct.
>
>
> Also, if there were control chunks that needed authentication, they  
> can't be
> bundled if the key changes?
>
> Seems like almost a protocol operation change to me.
Well, we never specified how the setsockopt affects the future  
sendcalls and
what the semantic is.
>
>
> If that is the case, this is now really begging for an ability to  
> specify
> key ID as ancillary data to sctp_sendmsg().
But this would be a change to sctp_sendmsg(). I'm sure Kachong does not
like it...
>
>
>
>> 8.1.23. Delete a shared key (SCTP_AUTH_DEACTIVATE_KEY)
>
> s/Delete/Deactivate/
Done.
>
>
>> This set option indicates that the application will not send user	
>> messages anymore requiring the usage of the indicated key  
>> identifier.	
>
> What about receiving messages?
You use the keys which are known by the kernel.
>
>
> Also, what about any pending messages already queued?  My guess is  
> that those
> should still be sent using the deactivated given key?
Yes.
>
>
> Should the key be allowed to be deleted (after deactivation) before  
> all the messages
> using it are sent?  My guess is no.
Correct.
>
>
> However, if the key can/should be deleted, should SEND_FAILED be  
> returned?
You can not delete the key as long as it is used...
> -vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 03 Nov 2008 16:32:37 -0500

Michael Tuexen wrote:
>> Also, shouldn't this event be generated when the key is actually removed
>    From now on the application will not use key anymore. When the kernel
>    does not need it anymore (for queued DATA transmission/retransmissions)

I guess, at this point, SCTP_AUTH_FREE_KEY is a misnomer, since the key is not
free as the name seems to imply.  SCTP_AUTH_INACTIVE_KEY might be better.

> Well, we never specified how the setsockopt affects the future sendcalls
> and
> what the semantic is.
>>
>>
>> If that is the case, this is now really begging for an ability to specify

Not really, since it's just an ancillary data to the sendmsg().  This is a
moot point however.

>>> messages anymore requiring the usage of the indicated key identifier.   
>>

My concern with the update API is that it subtly changes the behavior
of the protocol by associating a given key with the a given data.  It's
a fairly specific requirement and has limitations that have not been
specified in the AUTH spec.  Instead they are listed in a draft aiming
for informational status.

This could have been achieved by simply throttling the application since
this change was apparently triggered by the implementation of DTLS.

-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Nov 2008 22:54:53 +0100

Hi Vlad,

comments in-line.

Best regards
Michael

> free as the name seems to imply.  SCTP_AUTH_INACTIVE_KEY might be  
Well, the event basically tell the application that the ref count of the
key (if you use ref counting) is zero. It is up to the application to
delete the key. The reason why it is not automatically deleted is  
because
the kernel can not know if there might be packets coming in from the
network which require this key.

If you prefer SCTP_AUTH_INACTIVE_KEY and others agree, we can change it.
Opinions from others?
>> sendcalls
You wanted to add it to sctp_sendmsg(), so I guess you wanted to change
the function prototype of sctp_sendmsg(). I think that is hard...

However, I do not expect a lot of applications to use SCTP-AUTH  
directly.
So changing one of the main functions for a small portion of  
applications
seem not appropriate. We could add another function if you want...
> for informational status.
They are only related to the API. And the whole API stuff is only
Informational... So it seems for me the right place.
> this change was apparently triggered by the implementation of DTLS.
Sure, the DTLS/SCTP is the use case we use for testing... But Peter and
I discussed the API and tried to make it as useful as possible to also
allow future uses of it.