Re: two shim6-esd-00 comments

[Erik Nordmark <[e-mail]>]

Pekka Savola wrote:
> Hi,
> 
> Two smaller comments, probably already made, on 
> draft-nordmark-shim6-esd-00.txt:

Thanks for the comments. I'll make sure to include some more text about 
this in 01.

> 1) this obviously requires control over the reverse tree, which is by no 
> means given for generic shim6 audience, though it might be more popular 
> with sites which want to employ rewriting.
> 
>       The shim performs the identifier to locator lookup very similarly
>       to normal IPv6 reverse lookups (form a query name based on the
>       nibbles in reverse order and append ip6.arpa), but it queries for
>       SRV records.

Yes, but an important point is that it requires control of the reverse 
tree for the identifier and not for the locators.
Thus the site can get there locators from ISPs without any control of 
the DNS for those, and get their identifier from a separate entity which 
delegates IP identities. The identity prefix wouldn't be useful without 
giving out the delegation for their part of the deal.

> 2) In the latter part of the example below, AFAICS, are you able to use 
> the Sent Locator immediately?  This could be part of a 3rd party 
> [bombing] attack?  Does it need to be probed first or is this 
> sufficiently secure as it is?
>
>       B processes the I1 message as specified in [7] to generate a R1
>       message.  In addition, it copies the content of the Sent Locator
>       Pair option into a Received Locator Pair option.  Host B must
>       decide whether it should send the R1 message to the IP source
>       address of the R1 message, or send it to the potentially different
>       Sender Locator in the Sent Locator Pair option in the I1 message.
>       Once B has made this decision, it puts the addresses, in this
>       example <B1, A2> in the IPv6 header as well as into a Sent Locator
>       Pair option.

Using the Sent Locator option for the R1 reply would open up a 
reflection attack as you point out. Assuming ingress filtering will 
continue to be used, it would be safer to send the R1 to the source of 
the I1.

    Erik