DTLS: Add server side stateless and CID QoL API

[julek-wolfssl]

• wolfDTLS_accept_stateless - statelessly listen for incoming connections
• wolfSSL_inject - insert data into WOLFSSL object
• wolfSSL_SSL(Enable|Disable)Read - enable/disable reading from IO
• wolfSSL_get_wfd - get the write side file descriptor
• wolfSSL_dtls_set_pending_peer - set the pending peer that will be upgraded to regular peer when we successfully de-protect a DTLS record
• wolfSSL_dtls_get0_peer - zero copy access to the peer address
• wolfSSL_is_stateful - boolean to check if we have entered stateful processing
• wolfSSL_dtls_cid_get0_rx - zero copy access to the rx cid
• wolfSSL_dtls_cid_get0_tx - zero copy access to the tx cid
• wolfSSL_dtls_cid_parse - extract cid from a datagram/message

[rizlik]

I think this is a big step in the right direction but there are things unclear. These comments are considering wolfSSL/wolfssl-examples#472 as the user of the changes in this PR.

1. what's the purpose of splitting the fd in write and read?

2. I don't get why we should use the pendingPeer and the example doesn't use it. It looks complicate and there is code that get hit after we copy the pendingPeer to the current Peer that it doesn't look doing nothing other than flipping the processPendingRecord bit.

3. I don't see much gain in using wolfSSL_accept_stateless.
   AFAIU it just boils down in a) disabling read so that it can return before reading from the socket and b) to return after a good CH. a) avoids dropping other peer messages that can be received in the EmbedRecvFrom. But, as shown in the example, the server has already to read the messages itself outside of the wolfSSL to do proper demux. I wonder if then this is superfluous.

I would suggest of using a custom internal field like the pendingPeer, but called, as you suggested, currentRecordPeer.
Until the ssl is stateless, this is set on recvfrom, but no filtering happens bc of this.
It's used as the destination of the HRR/HVR and to compute the cookie.
It's not used anywhere else and it's not automatically copied over the other peer.
This way an ssl object can be used to reply to the CHs w/o cookies.
If we got a CH w/ valid cookie we can then leverage our existing goodch callback to set the right peer for sending and continue the connection.
If the application wants to demux, it needs to manage the reading from the socket itself anyway.

Just to recap, my suggestion are:

• In EmbedRecvFrom to set a "peer to send the HRR/HRV" to if we are in a stateless
• Application needs to use ChGoodCB to set the proper peer (is it already like this?)
• Make clear that application needs to manage the read itself if it wants to demux over a single socket

The new APIs (inject, parse_cid) allows the application to manage the connection with a good tradeoff of complexity and control imo.

[julek-wolfssl]

what's the purpose of splitting the fd in write and read?

It was always split. I just added a getter for that field.

I don't get why we should use the pendingPeer and the example doesn't use it. It looks complicate and there is code that get hit after we copy the pendingPeer to the current Peer that it doesn't look doing nothing other than flipping the processPendingRecord bit.
[...]
It's used as the destination of the HRR/HVR and to compute the cookie.

The pending peer is used in the example when CID's are used. The bit flipping is just to make sure that the pending peer is only valid for the next parsed record. We already have a good mechanism for cookie calculation, there is no need to change it. The pendingPeer is used in conjunction with CID's to validate the incoming record before updating the peer address. An off-path attacker sending records with the CID set can change the address if we don't first attempt to de-protect the record. Attempting to de-protect an off-path attacker's packets should fail and we will reject the pendingPeer internally without any extra help from the application needed.

I don't see much gain in using wolfSSL_accept_stateless.

You're the one who suggested adding it :D. I think it makes sense to have it to abstract away from the user the complexity of the stateless handling.

But, as shown in the example, the server has already to read the messages itself outside of the wolfSSL to do proper demux. I wonder if then this is superfluous.

But we also support a server object that reads from the network directly. We have to support that use case as well. This API helps a lot with that case to make sure no records are lost.

To respond to the suggestions:

In EmbedRecvFrom to set a "peer to send the HRR/HRV" to if we are in a stateless

Adding.

Application needs to use ChGoodCB to set the proper peer (is it already like this?)

It does not need to do that. It calls wolfSSL_dtls_set_peer for peers during the connection process. wolfSSL_dtls_set_pending_peer is used during the connection with CID's.

Make clear that application needs to manage the read itself if it wants to demux over a single socket

I think that is clear from the example. Where do you think we need more documentation?

[rizlik]

This looks better, thanks!

[julek-wolfssl]

@douzzer Learned to count and fixed the overflow. Fixed the clang-tidy errors too.