Question on wpa_supplicant setup for MKA

[Jaap Keuter]

Hi Sabrina,

Thanks for taking the time to look at this.
I’ve added my replies inline.


> On 28 Mar 2017, at 18:03, Sabrina Dubroca <sd at queasysnail.net> wrote:
> 
> Hi Jaap,
> 
> 2017-03-18, 23:54:03 +0100, Jaap Keuter wrote:
>> Hi list,
>> 
>> To study MACsec and MKA I've been experimenting with a setup using the Linux
>> kernel, the macsec kernel module and wpa_supplicant. So far I've managed to
>> establish SA's between statically configured MACsec instances, so that works,
>> and now I'm working on getting wpa_supplicant setup to handle MKA (with CAK/CKN).
>> 
>> The problem is that working with the Linux macsec driver
>> (CONFIG_DRIVER_MACSEC_LINUX=y). I'm not getting the result I expect.
>> First I use a 'normal' wired interface (eth0). When I run wpa_supplicant on that
>> interface the MKPDU's don't make it out to the network.
> 
> I guess that's where your problems come from. How do you check that
> the MKPDU's don't make it out? The receiving interface doesn't get
> them?
> 

Through the use of network namespaces I have ample opportunity to use Wireshark to show me what is going on on the various network interfaces. 
That is how I detected where the problem was, the MKPDU’s didn’t make it out of the ‘normal’ wired interfaces, being the veth equivalent of the eth0 interfaces in the network namespaces.


> [bit of reordering]
>> PPS: I'm using 'normal' wired interfaces, as in I use virtual Ethernet (veth)
>> interfaces to connect into two network namespaces where all the macsec and
>> wpa_supplicant instances live. These are connected to a (transparent) bridge.
> 
> You're using the Linux kernel "bridge" module then? It blocks these
> frames by default, until you run this:
> 
>    echo 8 > /sys/devices/virtual/net/$BRIF/bridge/group_fwd_mask
> 
> Or that, which should be equivalent:
> 
>    ip link set $BRIF type bridge group_fwd_mask 0x8
> 
> 
> This is, sadly, not documented much :(
> 

No, indeed, that is not very well documented. Fortunately I spend a lot of time at Layer 2, so I was aware of this pitfall.
I had already taking the measure you describe, which I tried to indicate by the use of the term ‘a (transparent) bridge’. 
The use of 'transparent' was my attempt to make that point, without confusing the Layer 3 people :)


> 
>> Then I stack a macsec
>> instance on top of eth0 (macsec0 at eth0) and run wpa_supplicant on that interface.
>> Now I'm getting an additional macsec instance on top of mine (macsec1 at macsec0).
> 
> Yeah, that's the expected behavior. MACsec uses another device on top
> of your link (like for VLANs), so wpa_supplicant will create it for
> you if it doesn't exist yet. If you tell wpa_supplicant to use macsec0
> as device, it will try to do macsec over macsec, I'm pretty sure
> that's not what you want ;)
> 

That does indeed open a whole new can—o—worms :)
And no, this is not what I wanted, this was merely an experiment to see what behaviour wpa_supplicant has.


>> But without SA's on macsec 0 that doesn't work either.
>> 
>> So the question is: how should wpa_supplicant be configured and started to make
>> this work? If you need more details, please don't hesitate to ask.
> 
> I use this mka.conf file:
> 
>    eapol_version=3
>    ap_scan=0
>    fast_reauth=1
> 
>    network={
>            key_mgmt=NONE
>            mka_cak=<16B CAK>
>            mka_ckn=<32B CKN>
>            eapol_flags=0
>            macsec_policy=1
>    }
> 
> 
> And run wpa_supplicant this way:
> 
> ./wpa_supplicant -i eth0 -Dmacsec_linux -c mka.conf
> 
> 

Thanks for sharing the config. It looks very much like mine. 

eapol_version=3
ap_scan=0
fast_reauth=1

network={
        key_mgmt=NONE
        eapol_flags=0
        macsec_policy=1
        macsec_integ_only=1
        mka_cak=0123456789ABCDEF0123456789ABCDEF
        mka_ckn=6162636465666768696A6B6C6D6E6F707172737475767778797A303132333435
        mka_priority=128
}

And to run wpa_supplicant

DEBUG_OPTS="-dd -K -t"
INTF=“eth0"
CONFIG="wpa_supplicant.mine.conf"
NS=“ns1"

${SUDO} ip netns exec ${NS} wpa_supplicant -D macsec_linux -c ${CONFIG} -i ${INTF} ${DEBUG_OPTS} >> ${LOGDIR}/wpa_supplicant_${NS}.log &

So I assume the relevant difference is that the virtual ethernet interface pair, which connects from the root namespace into the network namespace, doesn’t have the features wpa_supplicant needs.


In the mean time based on that assumption I’ve tried to see if another network interface could help here. To that end I’ve added a macvlan device in the network namespaces. 
This should allow wpa_supplicant to add on a macsec instance and allow me to have MACsec protected IP connectivity between the network namespaces.

#
# ns1 -------------------------------+
#              wpa_supplicant        |
# 10.0.0.1/8 - macsec0 - mac0 - eth0 + veth1 - |
# -----------------------------------+        bridge
# 10.0.0.2/8 - macsec0 - mac0 - eth0 + veth2 - |
#              wpa_supplicant        |
# ns2 -------------------------------+
#

When setting up this network, the network namespaces do show an elaborate stack of network interfaces:

jaap at host:~/MACsec[ns2]$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0 at if23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 86:78:22:b3:e4:3e brd ff:ff:ff:ff:ff:ff link-netnsid 0
3: mac0 at eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether a2:85:23:cb:a7:75 brd ff:ff:ff:ff:ff:ff
4: macsec0 at mac0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1468 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether a2:85:23:cb:a7:75 brd ff:ff:ff:ff:ff:ff

What thoroughly confuses me are the ‘state UNKNOWN’ clauses for ‘lo’ and especially ‘macsec0 at mac0’ (does it work now, or not?).
But it does seem to work. Pings go back and forth, the MACsec contexts after a few pings looks like this:

jaap at host:~/MACsec$ sudo ip netns exec ns1 ip macsec show
4: macsec0: protect on validate strict sc off sa off encrypt off send_sci on end_station off scb off replay off 
    cipher suite: GCM-AES-128, using ICV length 16
    TXSC: ee8fc1a19de60001 on SA 0
        0: PN 32, state on, key 739bd0e85e042c28af39a9a901000000
    RXSC: a28523cba7750001, state on
        0: PN 31, state on, key 739bd0e85e042c28af39a9a901000000

jaap at host:~/MACsec$ sudo ip netns exec ns2 ip macsec show
4: macsec0: protect on validate strict sc off sa off encrypt off send_sci on end_station off scb off replay off 
    cipher suite: GCM-AES-128, using ICV length 16
    TXSC: a28523cba7750001 on SA 0
        0: PN 32, state on, key 739bd0e85e042c28af39a9a901000000
    RXSC: ee8fc1a19de60001, state on
        0: PN 31, state on, key 739bd0e85e042c28af39a9a901000000

While on the veth1 and veth2 interfaces only EAPOL-MKA and MACsec frames are whizzing by.
So, can I claim success? I hope so. Have to test more of the features though.

Thanks,
Jaap


PS: I should look into the veth device code to see what’s keeping wpa_supplicant from working with it. The current interface stack is ridiculous :)