[Swan] Can you elaborate on this ?

Philippe Vouters philippe.vouters at laposte.net
Thu Jan 24 06:20:29 EET 2013 

An good document from Juniper regarding the topic I am focusing Elison's 
attention onto can be found 
http://kb.juniper.net/kb/documents/public/Performance/ns_perf.pdf

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

Le 24/01/2013 04:36, Philippe Vouters a écrit :
> 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