RE: Route Information Options in IPv6 Neighbor Discovery

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

Hi Fred,

A comment about SAVI/DHCP. RFC7513 seems to suggest DHCP snooping, i.e.,
some device on the path from the DHCP server to client examines the contents
of DHCP messages. Unfortunately, the DHCPv6 Security specification mandates
the use of encryption:

https://www.ietf.org/id/draft-ietf-dhc-sedhcpv6-21.txt

Does it mean that Secure DHCPv6 will be incompatible with SAVI?

Thanks - Fred

> -----Original Message-----
> From: Fred Baker [mailto:[e-mail]]
> Sent: Monday, April 17, 2017 5:42 PM
> To: Templin, Fred L <[e-mail]>
> Cc: Mikael Abrahamsson <[e-mail]>; james woodyatt <[e-mail]>; [e-mail]; Dave Thaler
> <[e-mail]>
> Subject: Re: Route Information Options in IPv6 Neighbor Discovery
> 
> We have essentially the same problem with IPv4 Source Guard, as several companies call the technology. It has been deployed since
> 2004 or thereabouts as proprietary technology, but operates essentially as SAVI/DHCP does. We don't observe the issue you raise.
> 
> A redirect in essence is router A telling some host that router B in the same subnet that would be a better choice - that router A's next
> hop for the indicated address is router B, and the host can be a good citizen by sending that traffic to B in the first place. If they're in
> the same subnet and the host can talk with both of them, the host is going to use the same source address and the same interface.
> SAVI is thrilled, and if the host does as it is told, we reduced message rate on the LAN a little bit.
> 
> Further discussion of SAVI should probably go to [e-mail]...
> 
> > On Apr 17, 2017, at 4:47 PM, Templin, Fred L <[e-mail]> wrote:
> >
> > I have a question on how SAVI interacts with the IPv6 Redirect function in general.
> > When a Router Redirects a Source to a Target, the Source has discovered something
> > that it did not know before, namely that a target IPv6 prefix is reachable via the
> > Target directly without having to go through the Router.
> >
> > Armed with this knowledge however, what is to stop the Source from sending packets
> > with spoofed IPv6 source addresses via the Target? And, this is an issue for standard
> > IPv6 Redirect for a singleton destination and not just for Redirects that include RIOs.
> >
> > That said, there is a way for the Source to tell the Target about the source address(es)
> > it intends to use by including the source addresses or prefixes in RIOs in a NS sent
> > to the Target before any data packets are sent. And, if the Source lies about any of
> > its addresses any SAVI L2 devices that examine the NS messages can drop them.
> >
> > Thanks - Fred
> >
> >> -----Original Message-----
> >> From: Fred Baker [mailto:[e-mail]]
> >> Sent: Sunday, April 16, 2017 11:19 PM
> >> To: Mikael Abrahamsson <[e-mail]>
> >> Cc: Templin, Fred L <[e-mail]>; james woodyatt <[e-mail]>; [e-mail]; Dave Thaler
> >> <[e-mail]>
> >> Subject: Re: Route Information Options in IPv6 Neighbor Discovery
> >>
> >>
> >>> On Apr 16, 2017, at 9:43 PM, Mikael Abrahamsson <[e-mail]> wrote:
> >>>
> >>> On Fri, 14 Apr 2017, Fred Baker wrote:
> >>>
> >>>>> SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine would be in scope for this documents security section. For
> >> instance, what would an SAVI enabled L2 switch that inspects ND entries do when it sees this RIO entry in ND?
> >>>>
> >>>> As specified, I think it would ignore them. It looks at the NA to determine what {IP address, MAC address} or {IP address, MAC
> >> address, Port #} association it should enforce. It has no illusion that this is the only data present.
> >>>
> >>> So the question becomes, is this desired behaviour? Sounds to me that there needs to be SAVI document enhancement for this
> RIO
> >> in ND then, for things to continue functioning properly (as I imagine if something sends RIO in ND to somewhere, there is
> expectation
> >> that any antispoofing device should allow for return traffic as well).
> >>
> >> Please feel free to make specific suggestions.
> >>
> >> https://tools.ietf.org/html/rfc6620
> >> 6620 FCFS SAVI: First-Come, First-Served Source Address Validation
> >>     Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M.
> >>     Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT=84010 bytes)
> >>     (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620)
> >>
> >> https://tools.ietf.org/html/rfc6959
> >> 6959 Source Address Validation Improvement (SAVI) Threat Scope. D.
> >>     McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT=62217 bytes)
> >>     (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959)
> >>
> >> https://tools.ietf.org/html/rfc7039
> >> 7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, J.
> >>     Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format:
> >>     TXT=31946 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7039)
> >>
> >> https://tools.ietf.org/html/rfc7219
> >> 7219 SEcure Neighbor Discovery (SEND) Source Address Validation
> >>     Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014.
> >>     (Format: TXT=90423 bytes) (Status: PROPOSED STANDARD) (DOI:
> >>     10.17487/RFC7219)
> >>
> >> https://tools.ietf.org/html/rfc7513
> >> 7513 Source Address Validation Improvement (SAVI) Solution for DHCP. J.
> >>     Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT=123735 bytes)
> >>     (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513)
> >>
> >> https://tools.ietf.org/html/rfc8074
> >> 8074 Source Address Validation Improvement (SAVI) for Mixed Address
> >>     Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E.
> >>     Levy-Abegnoli, Ed.. February 2017. (Format: TXT=23910 bytes)
> >>     (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074)
> >>
> >>
> >
> >
>