Re: Route Information Options in IPv6 Neighbor Discovery

[Fred Baker <[e-mail]>]

> On Apr 18, 2017, at 1:42 PM, Templin, Fred L <[e-mail]> wrote:
> 
> 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?

Great question for [e-mail].

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