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