[Swan-dev] IKEv1 and XFRMi interface

Antony Antony antony at phenome.org
Wed Sep 16 05:53:58 UTC 2020


I had a quic look. IKEv1 need extra message (3 round trips) as opposed to 
IKEv2(2 round trips). And initiator is installing policies in different 
order.

the test outputs as it is now are confusing because it seems a copy of IKEv2 
outputs. May be create tests with eastnet-westnet,  delete IKEv2 output and 
updated with broken IKEv1 outout. That would make analysing it quicker.

A better fix would be adding IKE pass policies, aka IKE holes, as XFRM 
policies. I suspect there are also ways add routing policie instead of XFRM 
polices, that is possibly what Android is doing.

One thing that would help to add IKE policies is use of  struct kernel_sa 
netlink_raw_eroute() same as  netlink_add_sa().  Now that KLIPS is gone we 
make this change. Keeping the shunt code as it is.


On Fri, Sep 04, 2020 at 12:15:05PM -0400, Paul Wouters wrote:
> On Fri, 4 Sep 2020, Antony Antony wrote:
> 
> > https://testing.libreswan.org/v3.30-1548-g6ff4d70e27-main/ikev2-xfrmi-01/
> > showing up as pass. So I am not following the issue.
> > Lets discuss this further on swan-dev!
> 
> That is an ikev2 test case, not an ikev1 test case.
> 
> kvmplutotest	ikev1-xfrmi-01				good
> kvmplutotest	ikev1-xfrmi-02				wip
> kvmplutotest	ikev1-xfrmi-02-aggr			wip
> kvmplutotest	ikev1-xfrmi-04				good
> kvmplutotest	ikev1-xfrmi-04-aggr			good
> kvmplutotest	ikev1-xfrmi-05-remote-access-client	good
> 
> 
> For ikev1-xfrmi-02 and ikev1-xfrmi-02-aggr we see:
> 
> 4 packets transmitted, 4 received, 0% packet loss, time XXXX
> 
>  ip -s link show ipsec1
> X: ipsec1 at eth0: <NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN
>     RX: bytes  packets  errors  dropped overrun mcast
>     0          0        0       0       0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     440        5        0       0       0       0
> 
> 006 #2: "road", type=ESP, add_time=1234567890, inBytes=0, outBytes=440, id='@east'
> 
> 
> So it looks like something weird is happening on the incoming byte stream? Like
> arriving in the clear?
> 
> Paul


More information about the Swan-dev mailing list