[Swan] Can you elaborate on this ?

[Philippe Vouters]

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
>
>