[Swan] Can you elaborate on this ?

Philippe Vouters philippe.vouters at laposte.net
Thu Jan 24 05:36:59 EET 2013 

An observed fact that Elison may exploit more digging into. Is there any 
valid network reason why his Netscreen runs emit smaller UDP packets in 
the aggressive phase, needing two to inform Libreswan of all its 
payloads, compared to the much larger UDP corresponding packets I 
observe on my side running Shrew ?

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

Le 23/01/2013 23:22, Nick Howitt a écrit :
> I've been watching this thread a bit and can I just make a point? So 
> far it has been shown that Shrew VPN behaves in a manner compatible 
> with LibreSwan. What you have not established is correct if the 
> LibreSwan is correct in its response to Netscreen. A valid test would 
> be between Shrew and Netscreen to see how the Shrew client responds to 
> the Netscreen case. It may be that the Shrew client works with both 
> scenarios. This would then indicate there may be a standards issue 
> with LibreSwan - but it still does not point you to the standard.
>
> Regards,
>
> Nick
>
> On 23/01/2013 14:20, Philippe Vouters wrote:
>> Elison,
>>
>> I have NOT YET read any strong evidence in the RFC's stored on Shrew 
>> Inc Web site (URL provided) that the second aggressive packet MUST be 
>> encrypted and that all payloads MUST be sent in the first unencrypted 
>> aggressive packet.
>>
>> If you succeed to find such an evidence, this will mean 
>> Libreswan/Openswan state machine algorithm which is the heart all the 
>> code is based onto is completely wrong.
>>
>> Philippe Vouters (Fontainebleau/France)
>> URL: http://vouters.dyndns.org/
>> SIP: sip:Vouters at sip.linphone.org
>>
>> Le 23/01/2013 14:45, Elison Niven a écrit :
>>> Hi,
>>>
>>> Yes you are right that there is no conclusive proof that who is 
>>> right in their implementation here, and that can only be reached 
>>> after reading the RFC's in detail.
>>>
>>> IMHO, I see three Vendors supporting this behavior on aggressive 
>>> mode so we might run into some standard/document/draft that 
>>> documents this.
>>>
>>> However, I have yet to find one !
>>>
>>> On Wednesday 23 January 2013 04:45 PM, Philippe Vouters wrote:
>>>> Dear Elison,
>>>>
>>>> The real problem which seems to appear is that Netscreen sends in the
>>>> second aggressive packet another payload in clear. Provided
>>>> Libreswan/Openswan would accept such a second agressive payload in
>>>> clear, this would completly break the Libreswan/Openswan logic 
>>>> which is
>>>> a state machine transitioning from one from one state to a 
>>>> successive one.
>>>>
>>>> As far as it looks, Shrew sends all its payloads in clear in the very
>>>> first packet. Because its second aggressive packet contains encrypted
>>>> data with flags=1, I cannot tell what is this second packet content 
>>>> from
>>>> the Wireshark trace.
>>>>
>>>> Either you or I should read in detail all the RFCs on the Shrew 
>>>> Soft Web
>>>> site I mentioned, you or I would surely tell who among Shrew/Libreswan
>>>> on one side and Netscreen/Fortigate, Netscreen/Sonicwall on the other
>>>> side is absolutely right.
>>>>
>>>> Between you and me, the fact that it works between Netscreen and
>>>> Fortigate or Sonicwall is indeed not a definite proof. Software 
>>>> history
>>>> highlights lots of workarounds to bugs. In the Libreswan /Openswan 
>>>> case
>>>> and provided it fully respects the IPSec RFCs, I can't imagine 
>>>> Libreswan
>>>> able to correctly working around this Netscreen case. As I said above,
>>>> Libreswan/Openswan is essentially a state machine.
>>>>
>>>> Philippe Vouters (Fontainebleau/France)
>>>> URL: http://vouters.dyndns.org/
>>>> SIP: sip:Vouters at sip.linphone.org
>>>>
>>>> Le 23/01/2013 10:53, Elison Niven a écrit :
>>>>> Hi,
>>>>>
>>>>> Yes that is what I indeed wanted to confirm.
>>>>> However, if you recall correctly, as I had stated earlier, This same
>>>>> setup works fine with :
>>>>> 1) Netscreen to Fortigate
>>>>> 2) Netscreen to Sonicwall
>>>>>
>>>>> Here also Netscreen is sending the 2nd packet as not encrypted 
>>>>> ,(Flags
>>>>> =0) and the other devices accept it.
>>>>> Is Libreswan missing some RFC/protocol that the other vendors are 
>>>>> using?
>>>>>
>>>>> On Wednesday 23 January 2013 03:04:09 PM IST, Philippe Vouters wrote:
>>>>>> Dear Elison,
>>>>>>
>>>>>> When comparing your Wireshark trace with a corresponding Wireshark
>>>>>> trace running Shrew VPN client, the problem is indeed visible on the
>>>>>> second Aggressive packet sent by Netscreen. It has flags=0 when 
>>>>>> Shrew
>>>>>> sets it to 1. Bit 1 of flags means encrypted.
>>>>>>
>>>>>> So there is definitely a bug on Netscreen side not respecting the
>>>>>> RFCs. If you need information onto the whole set of RFCs, go to
>>>>>> http://www.shrew.net/static/help-2.1.x/vpnhelp.htm?IPSecurity.html
>>>>>>
>>>>>> Philippe Vouters (Fontainebleau/France)
>>>>>> URL: http://vouters.dyndns.org/
>>>>>> SIP: sip:Vouters at sip.linphone.org
>>>>>>
>>>>>> Le 23/01/2013 05:05, Elison Niven a écrit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> Here are logs with plutodebug=all :
>>>>>>> http://pastebin.com/rVnGjiut
>>>>>>>
>>>>>>> If you need the wireshark capture, it is here :
>>>>>>> https://dl.dropbox.com/u/60175032/Netscreen-Libreswan-Aggr.pcap
>>>>>>>
>>>>>>> On Wednesday 23 January 2013 02:13:58 AM IST, Philippe Vouters 
>>>>>>> wrote:
>>>>>>>> I may also accept "both" as a valid answer. In which case, 
>>>>>>>> which side,
>>>>>>>> from Netscreen or Libreswan, is supposed to have modified this
>>>>>>>> smc->flags variable the last when it comes into the routine
>>>>>>>> process_packet ???? Shouldn't process_packet be better renamed to
>>>>>>>> process_incoming_packet ???
>>>>>>>>
>>>>>>>> Philippe Vouters (Fontainebleau/France)
>>>>>>>> URL: http://vouters.dyndns.org/
>>>>>>>> SIP: sip:Vouters at sip.linphone.org
>>>>>>>>
>>>>>>>> Le 22/01/2013 21:22, Philippe Vouters a écrit :
>>>>>>>>> Paul,
>>>>>>>>>
>>>>>>>>> You succeeded to totally confuse me in your successive 
>>>>>>>>> explanations
>>>>>>>>> for my actual understanding of Elison's problem. This is my only
>>>>>>>>> question to you after this mail of yours below:
>>>>>>>>> Which side, Netscreen or Libreswan, is supposed to set 
>>>>>>>>> smc->flags in
>>>>>>>>> the code extract I focus onto ???? Only one among the three 
>>>>>>>>> possible
>>>>>>>>> answers I accept : "don't know/not sure", "Netscreen", 
>>>>>>>>> "Libreswan".
>>>>>>>>>
>>>>>>>>> Philippe Vouters (Fontainebleau/France)
>>>>>>>>> URL: http://vouters.dyndns.org/
>>>>>>>>> SIP: sip:Vouters at sip.linphone.org
>>>>>>>>>
>>>>>>>>> Le 22/01/2013 20:13, Paul Wouters a écrit :
>>>>>>>>>> On Tue, 22 Jan 2013, Philippe Vouters wrote:
>>>>>>>>>>
>>>>>>>>>>> Can you give me with no hesitation which actual state
>>>>>>>>>>> corresponds to
>>>>>>>>>>> OAKLEY_AUTH_ROOF + 2 ? From the lecture of Libreswan source 
>>>>>>>>>>> code,
>>>>>>>>>>> getting this certainty is not trivial.
>>>>>>>>>>> OAKLEY_AUTH_ROOF + 2 conditions this loglog'ed message:
>>>>>>>>>>
>>>>>>>>>> These are just defines,
>>>>>>>>>>
>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_ALL_AUTH LRANGE(0,
>>>>>>>>>> OAKLEY_AUTH_ROOF-1)
>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_INITIATOR
>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 0)
>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define 
>>>>>>>>>> SMF_FIRST_ENCRYPTED_INPUT
>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 1)
>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_INPUT_ENCRYPTED
>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 2)
>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_OUTPUT_ENCRYPTED
>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 3)
>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define 
>>>>>>>>>> SMF_RETRANSMIT_ON_DUPLICATE
>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 4)
>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_REPLY
>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 5)
>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_RELEASE_PENDING_P2
>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 6)
>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_XAUTH_AUTH
>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 7)
>>>>>>>>>>
>>>>>>>>>> They are used for our own defines. There is probably a good and
>>>>>>>>>> smart
>>>>>>>>>> reason why Hugh originally based them on values >
>>>>>>>>>> OAKLEY_AUTH_ROOF, but
>>>>>>>>>> I don't know them.
>>>>>>>>>>
>>>>>>>>>>> smc in the code extract above is nothing but:
>>>>>>>>>>> smc = md->smc;
>>>>>>>>>>> and as per your explanation on md, I quote you:
>>>>>>>>>>> "
>>>>>>>>>>> md is the message digest, the stream of bytes from the incoming
>>>>>>>>>>> packet.
>>>>>>>>>>> "
>>>>>>>>>>> smc->flags should have been set by the Netscreen side.
>>>>>>>>>>
>>>>>>>>>> Not entirely, smc is the state machine microcode. The struct 
>>>>>>>>>> md is
>>>>>>>>>> defined as:
>>>>>>>>>>
>>>>>>>>>> struct msg_digest {
>>>>>>>>>>     struct msg_digest *next;    /* for free list */
>>>>>>>>>>     chunk_t raw_packet;         /* if encrypted, received packet
>>>>>>>>>> before decryption */
>>>>>>>>>>     const struct iface_port *iface;     /* interface on which
>>>>>>>>>> message arrived */
>>>>>>>>>>     ip_address sender;          /* where message came from 
>>>>>>>>>> (network
>>>>>>>>>> order) */
>>>>>>>>>>     u_int16_t sender_port;      /* host order */
>>>>>>>>>>     pb_stream packet_pbs;       /* whole packet */
>>>>>>>>>>     pb_stream message_pbs;      /* message to be processed */
>>>>>>>>>>     pb_stream clr_pbs;          /* place to store decrypted
>>>>>>>>>> packet */
>>>>>>>>>>     struct isakmp_hdr hdr;      /* message's header */
>>>>>>>>>>     bool encrypted;     /* was it encrypted? */
>>>>>>>>>>     enum state_kind from_state; /* state we started in */
>>>>>>>>>>     const struct state_microcode *smc;    /* microcode for 
>>>>>>>>>> initial
>>>>>>>>>> state (v1)*/
>>>>>>>>>>     const struct state_v2_microcode *svm; /* microcode for 
>>>>>>>>>> initial
>>>>>>>>>> state (v2)*/
>>>>>>>>>>     bool new_iv_set;
>>>>>>>>>>     struct state *st;   /* current state object */
>>>>>>>>>>     struct state *pst;  /* parent state object (if any) */
>>>>>>>>>>
>>>>>>>>>>     enum phase1_role role;
>>>>>>>>>>     msgid_t          msgid_received;
>>>>>>>>>>
>>>>>>>>>>     pb_stream rbody;    /* room for reply body (after header) */
>>>>>>>>>>     notification_t note;        /* reason for failure */
>>>>>>>>>>     bool dpd;           /* Peer supports RFC 3706 DPD */
>>>>>>>>>>     bool ikev2;         /* Peer supports IKEv2 */
>>>>>>>>>>     bool event_already_set;
>>>>>>>>>>     stf_status result;  /* temporary stored here for access by
>>>>>>>>>> Tcl */
>>>>>>>>>>
>>>>>>>>>> #   define PAYLIMIT 30
>>>>>>>>>>     struct payload_digest
>>>>>>>>>>         digest[PAYLIMIT],
>>>>>>>>>>         *digest_roof,
>>>>>>>>>>         *chain[ISAKMP_NEXT_ROOF];
>>>>>>>>>>     struct isakmp_quirks quirks;
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>> I did not mean to say md is _just_ the packet. Apologies for the
>>>>>>>>>> confusion.
>>>>>>>>>>
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Swan mailing list
>>>>>>>>> Swan at lists.libreswan.org
>>>>>>>>> https://lists.libreswan.org/mailman/listinfo/swan
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Best Regards,
>>>>>>> Elison Niven
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> Best Regards,
>>>>> Elison Niven
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Swan mailing list
>> Swan at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan
>
>

More information about the Swan mailing list