On Tue, 19 Feb 2019, Antony Antony wrote:
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.
Yes, i guess the "down" message would have to go on the "pending list".
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.
That probably requires code fixes. We should not bump the msgid and
indeed just retransmit the old one. Although that does make weird
for our dpddelay/dpdtimeout point of view. Since dpddelay would follow
our regular retransmit backoff, and the only thing needed would be the
dpdtimeout.
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
And is strictly not allowed per RFC. But I think in theory we could
create a mobike payload that satisfies all networks, that does not
rely on the IKE header for address update. That one in theory could
be send once over one interface, and then later over another interface,
as from a content point of view, the IKE payload is identical (although
the source IP is not)
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 think people agree at IETF this needs clarification.
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 believe Andrew already did some of this?
I think what we have is evolved from ikev1. Which does not have the n=1
model.
I think that's a very good point. We should see at maybe talking at IETF
about clarifying this.
Paul
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 <[email protected]> wrote:
New commits:
commit 6fa2fd9f21407581397d6cd6e7b24ebe6566378f
Merge: 4bc3929 87c192e
Author: Andrew Cagney <[email protected]>
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 <[email protected]>
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
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-commit
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
