[Swan-dev] Calling all Message ID bugs

[Antony Antony]

Here a few corner cases. 
what happens in case where
an admin type connection down in the middle of the rekey.
I mean the initial rekey message is lost and pluto is doing its retransmit 
cycle.  While it is doing that admin type a "auto --down/delete conn"

n=1 would suggest pluto can't initiate a delete informational message
until rekey message  is acknowledged. You have to go on retransmitting 
rekey.  While at it also think the same case without liveness/dpd and with 
liveness. They wold be different. 

I also think pluto jump message id when liveness is lost. Instead of 
re-transmitting old informational. You may run into that if you strictly 
implement n=1. 

Another corner case is mobike. Which one could test what iphone also.

As a thought experiment.
Say iphone is on LTE. IPsec connection is established. Say iphone is at 
message id 5. And you join a WiFi with captive portal or some kind or
filtering. iphone would send out mobike message 6, mobike probe.The probe,
message id 6, is lost for some reason, filtering or captive portal.  Then 
one of these happens say you disable wifi or leave the wifi, while the 
message id 6 is unacknowledged.

Can iphone initiate any new message exchange 7?
One could argue create a new empty informational with message id 6 and send 
it over lte link. Then it is not strictly retransmit of the previous message 
the content would vary. Source address would be different too, mobike 
message include a NAT-T payload which is derived from IP address phone got 
from the wifi network. Sending that payload over LTE sounds strange or 
rather should not do. I am yet to figure what what RFC mean strict n=1.

I am wonder how strict is pluto's n=1 with one tpacket per ike_st.
I think instead of tpacket (which is only the last messge "send" -- which 
could initiated or responded) we need
last_message_initiated and last_message_responded buffers for full
asynchronous exchange with message window n=1. Without we could run  into more 
corner cases.

I think what we have is evolved from ikev1. Which does not have the n=1 
model.

I started this e-mail a while agnd and forgot to send!
-antony

On Mon, Feb 04, 2019 at 12:38:10PM -0500, Andrew Cagney wrote:
> I've pushed the below re-implementation of IKEv2's Message ID code -
> used to identify re-transmits, route incoming responses to the correct
> state, and manage the send queue.
> 
> For the moment pluto continues to use values generated by the old
> code, but then compares those values against those generated by the
> new code - any discrepancies being debug-logged.
> The below are all bugs in the old code that the new code identified:
> 
> >         v2 msgids: hack process_encrypted_informational_ikev2() to patch up .st_msgid_lastack when a response
> >         v2 msgids: hack delete request so that the the current Message ID is saved in the IKE SA's .st_msgid
> >         v2 msgids: hack v2_msgid_update_counters() to not set .st_msgid_lastrecv=v2_INVALID_MSGID when MD is fake
> 
> I'm now wondering if anyone knows of any additional edge cases or bugs
> not covered by the testsuite (or WIP tests that should now work).
> 
> Over coming days I'll switch pluto to rely on the new code and values.
> The old code can then be deleted.
> 
> Andrew
> 
> On Mon, 4 Feb 2019 at 10:38, Andrew Cagney <cagney at vault.libreswan.fi> wrote:
> >
> > New commits:
> > commit 6fa2fd9f21407581397d6cd6e7b24ebe6566378f
> > Merge: 4bc3929 87c192e
> > Author: Andrew Cagney <cagney at gnu.org>
> > Date:   Mon Feb 4 10:22:47 2019 -0500
> >
> >     v2 msgids: implement simple MSGID strategy, shadow existing code
> >
> >     Merge commit '87c192e5229d3fca3c7161f6c9dea0e7a09d4bf0'
> >
> > commit 87c192e5229d3fca3c7161f6c9dea0e7a09d4bf0
> > Author: Andrew Cagney <cagney at gnu.org>
> > Date:   Wed Jan 30 22:58:20 2019 -0500
> >
> >     v2 msgids: add a new Message ID / window implementation, shadow existing code
> >
> >     The new code determines which IDs need updating using only the state
> >     transition's .send field and any incoming message.  It shadows the old
> >     code and, when debugging is enabled, pexpect()s discrepancies.
> >
> >     Of course there be dragons.
> >
> >     Here it come in the form of record 'n' send.  During a state
> >     transition, instead of adding the message to the outgoing queue and
> >     then letting success_v2...() send the next message in the queue, code
> >     is jumping the queue by recording 'n' sending messages mid-transition
> >     (bonus code also then deletes the state and message ...).
> >
> >     The new code gets around this by forcing a call to
> >     v2_msgid_update_sent().  The old code does:
> >
> >         v2 msgids: hack process_encrypted_informational_ikev2() to patch up .st_msgid_lastack when a response
> >         v2 msgids: hack delete request so that the the current Message ID is saved in the IKE SA's .st_msgid
> >         v2 msgids: hack v2_msgid_update_counters() to not set .st_msgid_lastrecv=v2_INVALID_MSGID when MD is fake
> >
> > _______________________________________________
> > Swan-commit mailing list
> > Swan-commit at lists.libreswan.org
> > https://lists.libreswan.org/mailman/listinfo/swan-commit
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev