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

["Templin (US), Fred L" <[e-mail]>]

Eduard,

> -----Original Message-----
> From: Vasilenko Eduard [mailto:[e-mail]]
> Sent: Friday, October 16, 2020 12:20 AM
> To: Templin (US), Fred L <[e-mail]>
> Cc: v6ops list <[e-mail]>; IPv6 List <[e-mail]>; Michael Richardson <[e-mail]>; dhcwg <[e-mail]>
> Subject: [EXTERNAL] RE: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
>
> Hi Fred,
> I do not fully agree to you.

We are talking past each other, and one of us does not have a clear understanding
of the issue at the heart of the discussion which I see as a forwarding plane issue
having nothing to do with the control plane.

Thanks - Fred

> 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
> > > > --------------------------------------------------------------------