[Swan] Can you elaborate on this ?
Philippe Vouters
philippe.vouters at laposte.net
Wed Jan 23 13:15:19 EET 2013
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
>
>
More information about the Swan
mailing list