Re: [Snac] M/O Bit reflection behavior of draft-hui-stub-router-ra-flag-02

[Erik Auerswald <[e-mail]>]

Hi Ted,

the problem I mentioned introduced rogue IPv6 routers ("Internet
Connection Sharing") that sent RAs without M or O flags, but the network
actually required DHCPv6, with correct RAs sent by the legitimate subnet
router with set M and O flags.  There was only one (redundant) DHCPv6
server involved.

The clients received a legitimate RA and configured themselves via DHCPv6.
Then they received a rogue RA, forgot the DHCPv6 address, and created
a new address via SLAAC in a different subnet.  This then repeated.
Hilarity ensued.

The unusually large amount of DHCPv6 requests was the first thing to come
to attention when troubleshooting the WLAN problems.

This is from quite a few years back, the network in question uses IPv6
since 2003 (mostly dual-stack with IPv4).

It does not matter how hosts are supposed to cope with inconsistent RAs.
It only matters how they do cope.  Back in the day, they did not cope
well.

I'd think the question is whether SNAC wants to play nice, or wants to
play rough ("if you manage your network, you must use RA Guard or suffer
the consequences").

Br,
Erik

P.S. IMHO some protection against IPv6 attacks is required for every
     managed network, be it RA Guard and friends, or dropping all frames
     with an Ethertype of 0x86DD.  Not every managed network is properly
     protected, though.


On Wed, Apr 17, 2024 at 08:37:04AM -0400, Ted Lemon wrote:
> The rogue router problem was really competing dhcp servers, so I don’t
> think we have to worry about that.  The current design is very much
> informed by that experience—you may recall that I was the author of one of
> the more popular dhcp servers at that time…  :)
> 
> Op wo 17 apr 2024 om 07:43 schreef Erik Auerswald <
> [e-mail]>
> 
> > Hi,
> >
> > back in the day, introducing rogue routers (i.e., Windows home systems
> > with their default behavior back then) into a managed WLAN using DHCPv6
> > resulted in client-side problems.  The clients would alternate between
> > DHCPv6 address assignment and SLAAC for the rogue prefix(es).
> >
> > Today, RA Guard should help.  It might interfere with SNAC, though. ;-)
> >
> > Br,
> > Erik
> >
> >
> > On Tue, Apr 16, 2024 at 10:22:52PM -0400, Ted Lemon wrote:
> > > Hm. The consensus that seemed to arise in discussion in the room(s) is
> > that
> > > we can't really fix this, and it doesn't make sense to try. That is, we
> > > shouldn't track the M&O bits sent by other routers. If they send
> > > inconsistent bits, too bad, the host stack already has to deal with that
> > > anyway.
> > >
> > > On Tue, Apr 16, 2024 at 6:15 AM Esko Dijk <[e-mail]>
> > > wrote:
> > >
> > > > > is the current requirement that the M&O bits be consistent between
> > RAs
> > > > actually a good idea? And separately, is it necessary?
> > > >
> > > >
> > > >
> > > > To get it 100% consistent all the time seems to make a solution complex
> > > > (as our past discussions about reboot corner cases show). It would
> > need a
> > > > distributed consensus algorithm.
> > > >
> > > >
> > > >
> > > > One simpler solution is
> > > >
> > > > 1 - copy/mirror the latest values advertised by a non-stub-router, if
> > any
> > > >
> > > > 2 - when a stub router boots/reboots, first send an RS to get
> > > > non-stub-routers on the link to respond to see their M/O flags, if any
> > > > (this RS is anyway needed after startup, to know whether existing
> > on-link
> > > > prefixes are “suitable” in the SNAC sense).
> > > >
> > > > 3 - if no regular routers are found (only SNAC stub routers) – then
> > > > advertise M&O flags with value ‘0’ . This may conflict with other stub
> > > > routers that advertise ‘1’ – but only for a limited time.
> > > >
> > > >   (Eventually these stub routers will switch back to ‘0’ or to the
> > > > RA-advertised value, if such a non-stub-router RA ever shows up again
> > in
> > > > the future)
> > > >
> > > >
> > > >
> > > > Agree with your 3 questions but I don’t know answers. Btw what does
> > > > “DHCPv6 is wanted” mean here – that the client or the higher layer
> > > > controlling this client gets a sudden instruction or preference for
> > > > obtaining a DHCPv6 based address/prefix/information ?
> > > >
> > > >
> > > >
> > > > Esko
> > > >
> > > >
> > > >
> > > > *From:* Ted Lemon <[e-mail]>
> > > > *Sent:* Wednesday, March 20, 2024 08:07
> > > > *To:* Suresh Krishnan <[e-mail]>
> > > > *Cc:* Esko Dijk <[e-mail]>; [e-mail]; 6MAN <
> > > > [e-mail]>
> > > > *Subject:* Re: [Snac] M/O Bit reflection behavior of
> > > > draft-hui-stub-router-ra-flag-02
> > > >
> > > >
> > > >
> > > > [Adding 6man to this discussion for reasons that will shortly become
> > > > apparent]
> > > >
> > > >
> > > >
> > > > Suresh and I had a conversation offline about persisting the M&O bits
> > > > advertised by other routers. Suresh accumulated quite a few battle
> > scars
> > > > over this back in the day. I think we could solve this problem, but
> > just
> > > > the stub router bit isn't going to be enough to solve it. And then the
> > > > question came up: is the current requirement that the M&O bits be
> > > > consistent between RAs actually a good idea? And separately, is it
> > > > necessary?
> > > >
> > > >
> > > >
> > > > I don't think we can answer that here, but it might be worth trying to
> > get
> > > > an answer to that before proceeding with a complicated solution. At
> > present
> > > > at least Apple BRs do not in fact reflect the M&O bits received from
> > > > infrastructure routers, and we haven't had any bug reports as a result.
> > > > That's not a particularly good indication, but I think it's worth
> > > > investigating what DHCPv6 IA_NA and IA_PD and Information-Request
> > clients
> > > > actually do when the M&O bits go away.
> > > >
> > > >
> > > >
> > > > There are three questions I would ask:
> > > >
> > > > 1. What happens if the M&O bits are advertised, and a DHCPv6 client of
> > any
> > > > of the three types starts, and then a new RA is seen with the relevant
> > > > bit(s) clear?
> > > >
> > > > 2. What happens if the M&O bits are not advertised, but DHCPv6 is
> > wanted,
> > > > and then an RA shows up with the M&O bits set. Does DHCPv6 start?
> > > >
> > > > 3. What happens if the we get an RA with the M&O bits set, and then an
> > RA
> > > > with them clear, and /then/ an indication that DHCPv6 is wanted?
> > > >
> > > >
> > > >
> > > > Some of these questions may not make sense in all situations, but I
> > think
> > > > this is the complete set of questions. Suresh's and my belief is that
> > once
> > > > a client has started doing DHCPv6, it's going to continue to do so
> > even if
> > > > it sees an RA with the relevant bit(s) clear. But it would be good to
> > test
> > > > that theory.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Mar 20, 2024 at 12:12 PM Suresh Krishnan <
> > > > [e-mail]> wrote:
> > > >
> > > >
> > > >
> > > > > On Mar 20, 2024, at 11:03 AM, Esko Dijk <[e-mail]
> > >
> > > > wrote:
> > > > >
> > > > > PS:
> > > > >
> > > > >> What the draft-hui-stub-router-ra-flag could do is just refer to
> > this
> > > > one, perhaps?
> > > > >
> > > > > My remark may not be fully clear. What I meant here is that the
> > sentence
> > > > stating that the values of M and O are mirrored, could refer to this
> > > > behavior with a sentence like "as defined in [draft-ietf-snac-simple]."
> > > > > This avoids explaining the mirroring in much detail within
> > > > draft-hui-stub-router-ra-flag. And it directly answers the question the
> > > > reader may have on how this works in detail.
> > > >
> > > > Thanks for that clarification Esko. That will certainly clarify the
> > > > intended behavior for this draft. I do have further concerns regarding
> > race
> > > > conditions copying bits between stub routers, but that is not a
> > concern for
> > > > this draft.
> > > >
> > > > Regards
> > > > Suresh