[j-nsp] Mirroring IPv6 neighbor advertisements

[James Stapley]

Somewhat late to the party, but I'm thinking about similar things at the
moment. We've not really had too many issues with this in the (many) years
we've been doing production IPv6, but now we're in the process of
considering rolling PI IPv6 out, and more extensively (into student VLANs
[where the naughty lives]), we're thinking about it fairly seriously.

Of course, if you mandated only EUI64 - and no cheating, in some way - that
solves part of the problem, but is entirely unrealistic, overly simplistic
(and possibly undesirable) in practice.

So, we're left with figuring out what the routers know.

If you're running SNMP on your (Juniper) subnet router/gateway device(s),
you can use SNMP to query a mapping between IP addresses and physical (MAC)
addresses - in essence, you're getting some version of the ND table in a
way that you can query remotely without needing to put another random
interface into each subnet or do some kind of port mirroring; this is, to
some extent, reasonably scalable (i.e. if you have shedloads of routers,
you may have multiple hosts polling and processing SNMP).

This is the most relevant SNMP OID I've found:
https://apps.juniper.net/mib-explorer/navigate.jsp#object=ipNetToPhysicalTable&product=Junos%20OS&release=17.3R3

It seems to do things like ignore leading zeroes in MAC addresses, so
you'll probably need to handle that.

Now what one needs to do is create a data structure to contain the parsed
information, together with:
1) Time this was the case (because when IP address X was in use by client Y
is often important; hello, Cease & Desist...)
2) Multiple IP to MAC mappings (because there can be many IPv6 addresses
per MAC over time, and at any point in time)
3) Tie in user identity (probably leveraging 802.1X either on wired ports
or through your wireless network) - you ought to then have both username
and MAC.

You can probably extend this in various ways (like perhaps what
physical/logical interface(s) they're learnt on, if that's not obvious from
the IPv6 subnet), if desired.

The joy of this is you also end up with a single source of truth, because
you can, at the same time, build up the same info for IPv4.

Obviously, you'll need to query ALL of your routers.

That all needs to be regularly slurped into a database of some kind, and
then you need some tools for your support agents / sysadmins to query it...

I've not yet gone much beyond thinking up the above, but it's going to need
to be built at some stage!

https://forums.juniper.net/t5/Security/L2-security-on-IPv6/ta-p/322231  has
some interesting thoughts to tackle at more or less the same time, if
you've not (yet) gotten to thinking about that.

<https://www.ru.ac.za>

James Stapley
Network Architect: I&TS Division
t: +27 (0) 46 603 8849
Struben Building, Artillery Road, Grahamstown, 6139
PO Box 94, Grahamstown, 6140, South Africa
www.ru.ac.za


On Fri, 22 Mar 2019 at 23:21, Jason Healy <jhealy at logn.net> wrote:

> We're starting to play around more with IPv6, and one thing we're missing
> is a log of who has which address.  In IPv4 we have DHCP and can check the
> logs, but we're using SLAAC for v6 so that's not an option.
>
> I set up a quick trunk interface with all our VLANs as members and started
> sniffing.  While I'm seeing plenty of neighbor discoveries, I'm not seeing
> any(?) neighbor advertisements.  I'm guessing that because the sniffing box
> doesn't have an address on each VLAN, it's not participating in ND and
> registering for multicast, so we're getting pruned.  IGMP snooping is on by
> default on all VLANs.
>
> I'd prefer not to have to add an interface on each VLAN just to grab all
> this traffic (more to keep in sync, security concerns, etc).  Is there a
> way to tell the switch to force IPv6 multicast traffic for ff02::1 to go to
> a specific port?  Our core is a QFX5100; the other switches in the network
> are a mix of EX3200/4200/3400.
>
> For the moment I've got it to work by setting up firewall filters on each
> VLAN in our core and port-mirroring just the ICMPv6 (type 136) traffic to a
> monitoring port.  That works, but it's also a lot of configuration
> overhead.  If there's a better way, I'd love suggestions!
>
> Thanks,
>
> Jason
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>