[Swan] Can you elaborate on this ?

[Elison Niven]

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