RE: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

[Vasilenko Eduard <[e-mail]>]

Hi Fred,
You need the challenge. OK. I have it for you.

Typical routing protocols would distribute to the "stub" router information about prefixes "somewhere in the network".
Prefixes from local interfaces are inserted into the routing table in the very persistent way:-)

DHCP-PD would distribute to the "stub" router information about prefixes that should become local/interface prefixes on the "stub".
Non-graceful reload could lead to amnesia on the "stub". Then it could attack its own uplink.
It is a new problem. Because DHCP-PD does play the role of "automatic provisioning system", not routing protocol.
The problem could be called "non-consistent routers configuration".
The fact that proper protocol for prefix distribution should be very similar to routing protocol - is the secondary here (it is implementation), because the problem itself is new.

Eduard
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Templin (US), Fred L
> Sent: 15 октября 2020 г. 1:37
> To: Bob Hinden <[e-mail]>
> Cc: v6ops list <[e-mail]>; IPv6 List <[e-mail]>; Michael Richardson
> <[e-mail]>; dhcwg <[e-mail]>
> Subject: RE: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay
> Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
> 
> > I note that the lack of “challenge” does not mean anyone agrees.   Agreement
> needs to be affirmative.
> 
> Fair enough, Bob; here is the assertion I made that I was referring to:
> 
> + BTW, I am still waiting to hear how this concern is in any way
> + specific to prefix delegation, since it seems to be generic to any
> + case of having a “stub” router that maliciously attacks its own
> + upstream link – no matter how that router negotiates its prefixes with
> upstream network nodes.
> 
> Do the individuals CC'd on this list agree that this is a generic IPv6 issue and not a
> DHCPv6-PD-specific issue?
> 
> Thanks - Fred
> 
> > -----Original Message-----
> > From: Bob Hinden [mailto:[e-mail]]
> > Sent: Wednesday, October 14, 2020 3:28 PM
> > To: Templin (US), Fred L <[e-mail]>
> > Cc: Bob Hinden <[e-mail]>; Michael Richardson
> > <[e-mail]>; dhcwg <[e-mail]>; IPv6 List
> > <[e-mail]>; v6ops list <[e-mail]>
> > Subject: Re: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay
> > Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay- requirements
> >
> > I note that the lack of “challenge” does not mean anyone agrees.   Agreement
> needs to be affirmative.
> >
> > Bob
> >
> >
> > > On Oct 14, 2020, at 3:24 PM, Templin (US), Fred L
> <[e-mail]> wrote:
> > >
> > > Bob, several messages back it was established that the issue at the
> > > heart of this discussion is not specific to DHCPv6 nor DHCPv6-PD.
> > > Instead, it is an issue that is common to any situation where there
> > > are multiple "stub" IPv6 routers on a downstream link from a
> > > "default" IPv6 router, no matter how the routing information is
> > > established or maintained. So far, no one has challenged my
> > > assertion that this is a generic (and not a DHCPv6-PD-specific) IPv6 issue and
> I have been waiting to see if anyone wants to challenge that.
> > >
> > > Fred
> > >
> > >> -----Original Message-----
> > >> From: Bob Hinden [mailto:[e-mail]]
> > >> Sent: Wednesday, October 14, 2020 2:47 PM
> > >> To: Templin (US), Fred L <[e-mail]>
> > >> Cc: Bob Hinden <[e-mail]>; Michael Richardson
> > >> <[e-mail]>; dhcwg <[e-mail]>; IPv6 List
> > >> <[e-mail]>; v6ops list <[e-mail]>
> > >> Subject: Re: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6
> > >> Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> > >> requirements
> > >>
> > >> With my chair hat on, is there a reason why this discussion is being copied
> to the 6MAN w.g.?   6MAN doesn’t maintain DHCP
> > related
> > >> items.
> > >>
> > >> Please remove [e-mail] from this thread.
> > >>
> > >> Bob
> > >>
> > >>
> > >>> On Oct 14, 2020, at 12:19 PM, Templin (US), Fred L
> <[e-mail]> wrote:
> > >>>
> > >>> Hi Michael,
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Michael Richardson [mailto:[e-mail]]
> > >>>> Sent: Wednesday, October 14, 2020 11:58 AM
> > >>>> To: Templin (US), Fred L <[e-mail]>
> > >>>> Cc: [e-mail]; Jen Linkova <[e-mail]>; dhcwg
> > >>>> <[e-mail]>; v6ops list <[e-mail]>; 6man
> > >>>> <[e-mail]>
> > >>>> Subject: Re: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to
> > >>>> DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-
> > >> relay-
> > >>>> requirements
> > >>>>
> > >>>>
> > >>>> Templin (US), Fred L <[e-mail]> wrote:
> > >>>>> Michael, what I was referring to below as "failure" is the proxy
> > >>>>> case when there is an L2 proxy P between the client and relay
> > >>>>> (e.g., RFC489). There
> > >>>>
> > >>>> RFC4389 describes an ND Proxy.
> > >>>> Is that really an L2 proxy?
> > >>>
> > >>> Yes, I believe it is an L2 proxy.
> > >>>
> > >>>> It seems like it also must be contain either an L2-bridge, or
> > >>>> must have the L3-routing table entries if it would really be
> > >>>> capable of passing DHCPv6-PD prefixes through it.
> > >>>
> > >>> The only thing it has that includes L3 information is neighbor
> > >>> cache entries that keep track of the client's actual L2 address on
> > >>> the downstream link segment, but rewrites the client's L2 address
> > >>> to its own L2 address when forwarding onto an upstream link
> > >>> segment. (In the reverse direction, it receives packets destined
> > >>> to its own L2 address but the client's L3 address on the upstream
> > >>> link segment, then rewrites the L2 address to the client's L2
> > >>> address when forwarding onto the downstream link segment.)
> > >>>
> > >>>> Can you explain how such a device would normally work for a
> > >>>> client device A,B,C,D doing DHCPv6-PD through it?
> > >>>
> > >>> Sure. A sends a DHCPv6 Solicit using its IPv6 link-local address
> > >>> as the source, and its L2 address as the link-layer source. The
> > >>> proxy converts the link-layer source to its own L2 address when
> > >>> forwarding the DHCPv6 solicit onto the upstream link. When the
> > >>> DHCPv6 Reply comes back, the IPv6 destination is that of client A, but the
> link-layer destination is the L2 address of the proxy.
> > >>> The proxy then converts the L2 destination to the address of
> > >>> client A and forwards it on to the client.
> > >>>
> > >>>> And is the failure one where the router "R" fails to drop traffic
> > >>>> it should, one where the router "R" drops traffic that it shouldn't?
> > >>>
> > >>> I was thinking more along the lines of the latter; if the only way
> > >>> that A has for talking to B, C, D, etc. is by going through R, it
> > >>> wouldn't work if R was unconditionally dropping everything.
> > >>>
> > >>> Thanks - Fred
> > >>>
> > >>>> --
> > >>>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> > >>>>          Sandelman Software Works Inc, Ottawa and Worldwide
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>> ------------------------------------------------------------------
> > >>> -- IETF IPv6 working group mailing list [e-mail]
> > >>> Administrative Requests:
> > >>> https://www.ietf.org/mailman/listinfo/ipv6
> > >>> ------------------------------------------------------------------
> > >>> --
> > >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------