[Swan] Can you elaborate on this ?
Elison Niven
elison.niven at cyberoam.com
Wed Jan 23 15:45:45 EET 2013
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
>>
>>
>
>
>
--
Best Regards,
Elison Niven
More information about the Swan
mailing list