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@xxxxxxxxxxxxxxx> 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@eth0) and run wpa_supplicant on that interface.
>> Now I'm getting an additional macsec instance on top of mine (macsec1@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@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@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@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@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@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@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@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 :)
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
