On 2019-10-31 2:24 a.m., Benjamin Kaduk via Datatracker wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
There are some seriously low-hanging fruit for traffic analysis with
some of these messages, e.g., any OSCORE request with 'kid' of "JRC" is
going to be a parameter update, at present. If someone wanted to throw
out some chaff and muddle up this traffic analysis, what options are
available to them?
Any parameter Update Request occurs between the JRC and the
already/previously on-boarded device. So it occurs over the 802.15.4 L2
key(s). It shouldn't visible against other CoAP traffic such as CoAP
GET requests of sensor data.
There are three kinds of traffic that would be seen by a pervasive monitor:
1) L2 traffic that is encrypted. It has a src/dst L2 address visible,
which is probably an assigned 2-byte "short" address. (Which is assigned
by this protocol.)
2) Beacons that are authenticated but not encrypted. Pledges can not
authenticate the beacons as they haven't the right key (yet). Others
can, and this lets them sync to the schedule and update their ASN.
They have an 8-byte source address.
3) Join traffic which is not encrypted or authenticated, which has
8-byte source and 8-byte destinations, probably using vendor assigned
EUI-64, but could be randomized EUIs. ALL of this traffic is probably
join traffic. Yes, it is easily visible.
A PM can probably also guess which encrypted traffic relates to the join
messages by a simple co-relation of message sizes, but that's not really
that new.
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
