[Swan-commit] Changes to ref refs/heads/master

[Paul Wouters]

New commits:
commit f808d8a12e28d5bd9492b0cd71c553705160f096
Author: Paul Wouters <pwouters at redhat.com>
Date:   Wed Aug 13 20:33:20 2014 -0400

    updated changes

commit 9e0b402716953927aedc67be3fba0e7b2573baf0
Author: Paul Wouters <pwouters at redhat.com>
Date:   Wed Aug 13 20:27:15 2014 -0400

    IKEv2: ikev2_update_counters() usage updated
    
    - process_encrypted_informational_ikev2() should use ikev2_update_counters()
      instead of manually setting st->st_msgid_lastrecv
    - ikev2_update_counters() used this often confused md->role variable. It
      now uses the ISAKMP_FLAGS_MSG_R directly to avoid future confusion.
    - ikev2_update_counters() blindly copied in the packets last msgid, instead
      of first making sure it was actually higher than the last one we had received.

commit 7407c15a9f636e8a3d061d2b5163802f5119f7a6
Author: Paul Wouters <pwouters at redhat.com>
Date:   Wed Aug 13 20:22:04 2014 -0400

    IKEv2: clarify code wrt Original responder/initiator and Request/Reply packet
    
    - Rename ISAKMP_FLAGS_I to ISAKMP_FLAGS_IKE_I
    - Rename ISAKMP_FLAGS_R to ISAKMP_FLAGS_MSG_R
    - Rename INITIATOR/RESPONDER to O_INITIATOR/O_RESPONDER
    - Fixup logging in process_v2_packet() to clearly log both the
      Original Initiator/Responder and the current packet Request/Reply flags.
    
    NOTE: the narrowing code is using O_INITIATOR/O_RESPONDER to determine
    if it is a responder/initiator. This is technically wrong, but works out
    now because for the IKE_INIT_SA/IKE_AUTH exchanges, the Original Initiator
    is always the Message Requester.

commit 40110e62ff7a679ac16996dbda5704910e144571
Author: Paul Wouters <pwouters at redhat.com>
Date:   Wed Aug 13 20:11:34 2014 -0400

    IKEv2: Don't respond to respond messages when parent SA was not found
    
    IKEv2 exchanges are always pair wise. One request causes one respond.
    The ISAKMP_FLAGS_R marks a packet as a response (not a request)
    
    However, this check was for ISAKMP_FLAGS_I, which is wrong. The
    ISAKMP_FLAGS_I flag has nothing to do with whether a message is a
    request or a response. It only indicates which party initiated the
    IKE (parent) SA in the original IKE_INIT_SA exchange. This is used
    only to determine which SPI/KEY we need to use to match or
    encrypt/decrypt the packet.
    
    In other words: !ISAKMP_FLAGS_I != ISAKMP_FLAGS_R

commit 38ae593bb3d31e08bfcc5aa5420a3a01880d7c32
Author: Paul Wouters <pwouters at redhat.com>
Date:   Wed Aug 13 20:04:05 2014 -0400

    IKEv2: first initiating exchange of Original Responder is not a retransmit
    
    st->st_msgid_lastrecv was not initialised to v2_INVALID_MSGID, so it was 0.
    This resulted in the first exchange initiated by the Original Responder,
    that has msgid 0, to be misinterpreted as an IKE_INIT_SA retransmit. The
    packet was then dropped.
    
    For both recent and old retransmit checks, take the v2_INVALID_MSGID value
    as special - there has never been an exchange initiated by that side.

commit 14faed682aa8ca73b1a1eb0f75cd723622b5b792
Author: Paul Wouters <pwouters at redhat.com>
Date:   Wed Aug 13 15:43:20 2014 -0400

    rename two flags for clarity
    
    I keep forgetting/relearning that we have two flags for two different
    initiator/responder states. One flag indicates the IKE originator,
    so we know which SPI's are theirs/ours. The other flag indicates the
    MESSAGE originator, so we know if we should reply or not.
    
    These flags were named ISAKMP_FLAG_INIT and ISAKMP_FLAG_RESPONSE. It
    keeps suggesting to people that these two flags cannot occur at once,
    but they can.
    
    I renamed these to ISAKMP_FLAG_IKE_INIT and ISAKMP_FLAG_MSG_RESPONSE.