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

[Vasilenko Eduard <[e-mail]>]

Hi Fred,
I do not fully agree to you.

Yes, such data plane problem (like you described) could happen in the ordinary routing environment.
Theoretically, it could be created by routing protocol (in control plane).
Practically, all routing protocols are robust enough for such situation not to happen - they do have some means to synchronize states (at least tracking "neighbors").

But it is not related to DHCP-PD discussion.
DHCP-PD is stateless without information synchronization after link up. Even "link up" is not possible to track if it is multi-hop through bridge.
It is easy to create such amnesia: just push power button on the stub router.

Hence, I do not understand the point of your generalization.
It is not proper generalization, because it does not work in all environments.
Especially it is important that it does not work in DHCP-PD environment.

Eduard
> -----Original Message-----
> From: Templin (US), Fred L [mailto:[e-mail]]
> Sent: 15 октября 2020 г. 22:31
> To: Vasilenko Eduard <[e-mail]>
> Cc: v6ops list <[e-mail]>; IPv6 List <[e-mail]>; Michael Richardson
> <[e-mail]>; dhcwg <[e-mail]>
> Subject: RE: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors
> regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
> 
> Eduard,
> 
> Thanks for your message. The point I was trying to make is that if the upstream
> router R is convinced - through whatever means - that the downstream stub
> router S holds an IPv6 prefix such as 2001:db8:a:b::/64, then it will forward all
> IPv6 packets with destination address from that prefix to S *even if the packets
> originated from S*.
> That is not a new issue brought about by DHCPv6, since it is  a forwarding plane
> issue and not a control plane issue.
> 
> Fred
> 
> > -----Original Message-----
> > From: Vasilenko Eduard [mailto:[e-mail]]
> > Sent: Thursday, October 15, 2020 12:12 PM
> > To: Templin (US), Fred L <[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
> >
> > 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
> > > --------------------------------------------------------------------