[Swan] Can you elaborate on this ?

[Philippe Vouters]

Paul, Elison

So far facts :
- Netscreen thinks it is time for phase 2 when Libreswan is still in 
phase 1.
- From Elison's # ipsec auto --status command, Libreswan is expecting 
Aggregate I2 which does not come.
- the loglog in the code block I pointed out is triggered.
- Elison did not show the effect of the 
SEND_NOTIFICATION(INVALID_FLAGS); on Netscreen side. Apparently this 
SEND_NOTIFICATION is ignored by Netscreen, backed up by the fact 
Netscreen thinks it is time for phase 2 when it is not. This should be 
code missing on the Netscreen side.

Questions:
- Is the loglog'ed message which is triggered the root cause for 
Libreswan still expecting I2 and never going through ? Apparently the 
code extract does reject the network packet.
- Is the loglog'ed message fully justified ?

Further facts to be collected by Elison:
A Wireshark trace taken on the Librewan side filtered on 'src or dst 
<Netscreen IP address> udp port 500 or udp port 4500'. If Elison can put 
the Wireshark trace onto an FTP server so that I can download it and 
study it, this ought to be great. I would like to attempt to retrieve 
the rejected packet.

Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org

Le 22/01/2013 17:47, Paul Wouters a écrit :
> On Tue, 22 Jan 2013, Philippe Vouters wrote:
>
>> Part or all of Elison's problems is caused by this in 
>> ./programs/pluto/ikev1.c:
>>     {
>>        /* packet was not encryped -- should it have been? */
>>
>>        if (smc->flags & SMF_INPUT_ENCRYPTED)
>>        {
>>            loglog(RC_LOG_SERIOUS, "packet rejected: should have been 
>> encrypted");
>>            SEND_NOTIFICATION(INVALID_FLAGS);
>>            return;
>>        }
>> It gets conditionally executed when if (md->hdr.isa_flags & 
>> ISAKMP_FLAG_ENCRYPTION) reveals false.
>> SMF_INPUT_ENCRYPTED is a macro inside the same source file which is 
>> set to:
>> #define SMF_INPUT_ENCRYPTED     LELEM(OAKLEY_AUTH_ROOF + 2)
>>
>> OAKLEY_AUTH_ROOF is defined as:
>> #define OAKLEY_AUTH_ROOF           8  /*roof on auth values THAT WE 
>> SUPPORT */
>> ./include/ietf_constants.h
>>
>> Can you justify a bit more on the pertinence or not of the above 
>> loglog(RC_LOG_SERIOUS,...) that Elison faces ????
>
> SMF stands for State Machine Flags. Those are predicates that must be
> met to be a valid packet for a certain state in the state machine.
>
> When we initiate or respond to a connection, an "instance" is created
> for that connection with a state object (see struct state). The state
> machines defines the valid states. For each state, following the RFCs,
> certain conditions must be met. These are encoded with the SMF_* flags.
> When processing an incoming packet, a state change transition may
> happen. These are encoded in the STF_XXXX messages, such as:
>
> STF_OK: state changed successfully
> STF_FAIL: state change not successful. Usually this triggers sending a
> packet with an error condition, such as NO_PROPOSAL_CHOSEN.
> STF_INLINE: an internal state change (not based on RFC). Usually refers
> to helper processes that we wait on.
> STF_FATAL: we should never have reached this point. There is an error in
> our code - launch assertion failure, dump core, and restart daemon.
> STF_IGNORE: we are remaining in the same state, awaiting a new event.
>
> pluto is event based. State changes happen as a result of an event. This
> could be receiving a packet, a timer based event, or our select() call
> receiving an event (eg crypto helper ready, whack command on socket)
>
> The terms I and R in MAIN_I1 or AGGR_R2 stands for the mode (main mode,
> aggressive mode, quick mode, etc) followed by the I for initiator states
> and R for responder states, followed by the packet number. Functions
> related to the state have names that signify what comes in, and what
> goes out, so aggr_inI2_outR2() is called only when the state is in
> Aggressive mode R1, and we are waiting to receive the second packet from
> the initiator, upon which we will send out the second packet as
> responder and move into the Aggr R2 state (which if you would look at
> the state table, would be expecting a Quick Mode I1 packet)
>
> md is the message digest, the stream of bytes from the incoming packet.
> It contains the IKE (ISAKMP) header of the incoming packet. The IKE 
> header
> of the incoming packet contains a flag stating whether or not the packet
> is encrypted. So for each state in the state machine, we compare the
> received "encryption flag" (md->hdr.isa_flags & ISAKMP_FLAG_ENCRYPTION)
> with the expected state machine "encryption flag" (SMF_INPUT_ENCRYPTED)
>
> The ROOF and LELEM are constructs designed by Hugh Redelmeier to ease
> the checking of certain flags and switch cases. You normally iterate
> until you hit the ROOF. If you hit the ROOF, it means what that what
> you were looking for was not found. ROOF is like "maximum". I find the
> construct of LELEM complicated, it is deeply depending on MACRO's. I
> should have an explanation by Hugh somewhere in old email that I can try
> to find for you at a later date. So I cannot tell you right now how the
> construct of LELEM works with a ROOF + value, but I am fairly confident
> that the code is correct. Perhaps Hugh can elaborate further.
>
> As stated in my answers on the list, I am pretty sure the "encrypted"
> versus "unencrypted" messages are due because of a disagreement between
> the parameters of the connection. Because this is Aggressive Mode, and
> exchanging parameters and Diffie-Hellman happen concurrently (unlike in
> Main Mode where DH is completed before parameters are exchanged, but it
> takes double the number of packets exchanged, so has double the
> latency in establishing the connection)
>
> One could argue a new state in the state machine could be made where we
> can go and receive an unencrypted message, and parse the notification
> payload. This state would not allow to move into Aggr R2.
>
> But we are remaining in the same state because we could still receive a
> properly encrypted message. An unencrypted message could be send by an
> attacker to mislead us, so we cannot make any state machine changes based
> on such an unsecured packet that could have been spoofed. So we log it,
> and remain waiting for a proper packet that complies with the RFCs as
> implemented in our state machine. This is likely signaled by the
> function returning STF_IGNORE (I did not look it up)
>
> Paul
>