[Swan] test case aborts, such as ikev2-x509-14-san-dn-mismatch

[Andrew Cagney]

I looked at xauth-pluto-26 and east seemed to be receiving zero
packets so I kicked testing.

On Tue, 5 Mar 2019 at 21:51, Paul Wouters <paul at nohats.ca> wrote:
>
>
> I looked at the many slow failures we are seeing for tests that are
> supposed to fail to establish a connection. the test harnass now
> times out on these, eg:
>
> https://testing.libreswan.org/v3.27-930-g9df3f69c7-master/ikev2-x509-14-san-dn-mismatch
>
> The issue is that the last retransmit before we release the hack is at 32s:
>
> 010 "san" #2: STATE_PARENT_I2: retransmission; will wait 32 seconds for response
> 002 "san" #2: certificate verified OK: E=user-east at testing.libreswan.org,CN=east.testing.libreswan.org,OU=Test Department,O=Libreswan,L=Toronto,ST=Ontario,C=CA
> 003 "san" #2: ID_DER_ASN1_DN 'E=user-east at testing.libreswan.org,CN=east.testing.libreswan.org,OU=Test Department,O=Libreswan,L=Toronto,ST=Ontario,C=CA' does not match expected 'C=CA, ST=Ontario, L=Toronto, O=Libreswan, OU=Test Department, CN=NOTeast.testing.libreswan.org, E=user-NOTeast at testing.libreswan.org'
> 002 "san" #2: Peer public key SubjectAltName does not match peer ID for this connection
> 002 "san" #2: X509: CERT payload does not match connection ID
> 224 "san" #2: STATE_PARENT_I2: v2N_AUTHENTICATION_FAILED
> 002 "san" #2: deleting other state #2 (STATE_PARENT_I2) and NOT sending notification
> 002 "san" #1: deleting state (STATE_PARENT_I2) and NOT sending notification
>
> The 32s is putting us over the 60s wait period in the python expect
> code and thus causing the failure.
>
> The old behaviour was to error after the first AUTH failed:
>
> 002 "san" #2: Peer public key SubjectAltName does not match peer ID for this connection
> 002 "san" #2: X509: CERT payload does not match connection ID
> 224 "san" #2: STATE_PARENT_I2: v2N_AUTHENTICATION_FAILED
> 031 "san" #2: STATE_PARENT_I2: 10 second timeout exceeded after 0 retransmits.  Possible authentication failure: no acceptable response to our first encrypted message
> 000 "san" #2: starting keying attempt 2 of an unlimited number, but releasing whack
> west #
>
>
> I the think old behaviour was correct. The AUTH payload failed but not
> because of a failure of encryption or integrity. It is simply not
> allowed to because it is the wrong IKE ID. There won't be coming a
> better answer on this exchange. It is not a forged/bad packet.
>
> I'll redo a git bisect tomorrow and see why it changed.
>
> Paul
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan