Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

[Mark Smith <[e-mail]>]

On Tue, 28 May 2019 at 00:00, Nick Hilliard <[e-mail]> wrote:
>
> David Farmer wrote on 24/05/2019 14:35:
> > On Fri, May 24, 2019 at 3:59 AM Nick Hilliard <[e-mail]> wrote:
> >     the usual ietf position is that operational misconfig - including
> >     daemons crashing - is out of scope for protocol development.  If it's
> >     out of scope, there's no real issue regarding consensus.
> >
> >     Obviously, from an operational point of view, if DHCP service is
> >     important on a network, the operator is at liberty to install redundant
> >     servers / relays.
> >
> > WHAT ARE ARE YOU SAYING?
>
> nothing more than the sober reality of GIGO - garbage in, garbage out.
> DHCP, as a protocol, expects correct configuration.
>
> Is it a problem with the protocol if someone mis-types a MAC address in
> the config?  Or specifies the wrong next-hop gateway?  Or makes a
> mistake in an autoconfig URL?  All these things could be fatal for the
> device under configuration.  Fixing this is not a protocol-layer problem.
>
> > The IETF SHOULD NOT concern itself with
> > accidental misconfiguration? And SHOULD only create fragile and brittle
> > protocols? The IETF SHOULD NOT seek robustness in its protocols?
>
> These issues are, to some degree at least, orthogonal to each other: you
> can build solid protocols which are inherently susceptible to problems
> with misconfigs. On the other hand, implementations can be built to work
> around this by implementing sanity checking.
>
> Regarding misconfigs and crashing in general, DHCP has been around for a
> long time. This means that people understand how it works - i.e.
> misconfigs can usually be solved quickly - and the implementations are
> generally pretty robust - i.e. crashes are rare and if you need
> resilience, you can use multiple separate servers / relays (a
> protocol-layer feature).

Hosts should trust the configuration information the network provides.

It's binary.

What I don't understand it some people seem to be quite fine with
rogue RAs, meaning they're happy to have hosts universally trust
received RAs, rogue or not, until this flag was proposed.

If a host can't trust the configuration information that the network
provides, then that obligates the network operator to make the
information that the network provides to always be trustworthy, by
implementing RA Guard, or isolating unstrusted hosts to their own
individual point-to-point links with their only other peer being an RA
issuing router.

If this flag is received and it is to be considered potentially bogus,
then anything already received in any RAs is already potentially
bogus. The whole RA should be considered bogus, as should all other
RAs received from any other RA issuers on the link.

Hosts can be assured of what they received by implementing and
requiring SEND. If a network doesn't implement SEND, then the network
is implying that what ever is received is not bogus, regardless of its
source.

In other words, without any form of authentication i.e. SEND, it is a
simple as trusting everything received or trusting nothing received.
If RAs are being accepted by hosts, rather than being universally
ignored, then they should be trusting everything in the RA received,
including this flag.

>
> Nick
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------