Re: [Mip6] Re: RFC2136 and IP address ownership

[Paul Vixie <paul@vix.com>]

james,

# The three way handshake you talk about is what the MIP6 community calls
# "return routablility"; that is, a proof that a node claiming to be at a
# particular IP address is, indeed, at that address.

well, i'd hate to call it a "proof".  it's a strong hint.  confidence level
is higher if 3-way TCP completes than if a simple UDP arrives.  but it's not
100% confidence and i'd expect the "Security Considerations" to word this
very carefully.  3-way TCP is the .rhosts of this decade -- trivially useful
but not strong enough for serious security work.

# As you point out, RFC 2136 seems to be lacking this proof, which makes it
# difficult to use for end node updating of FQDNs, since an end node that
# sends an authenticatable (via TSIG or SIG0, as pointed out by Olafur)
# message updating a DNS record may, in fact, be attempting to propagate a
# redirection attack if the address actually belongs to another node.

i'd say that key compromise is out of scope for RFC 2136 or any technology
based on it.  a simple caveat, "by the way, if the key is compromised, then
all bets are off," is all anyone could expect.

# If there is some interest in working on this in the DNS community, I think
# people in the MIP6 group would be happy to work together to provide
# requirements and review, since we really need this in order to allow end
# node updating of dynamically allocated home addresses. I think the DHC WG
# could also benefit, since DHCP allocated addresses have a similar security
# issue (though they might not have considered it yet).

in an old DDNS-DHC Interaction draft, yakov asserted that a dhcp server was
very likely to be under the same security regime as the ddns server, and that
a DHCP protocol option whereby a dhcp client asked the dhcp server to please
update the PTR, would be likely to find traction in most cases.  i still agree
with that reasoning, but for reasons i wasn't party to, it was never finished.

the need for this as an ietf standard is itself questionable, since it's not
a case where interoperability can be tested.  either a ddns server has a "self"
ACL and permits a ddns client to update RRsets pertaining to its "in-addr", or
it won't.  however, i think the feature is missing, and that even if various
implementors all implement this differently -- which wouldn't be a problem
since there are no interoperability issues afoot -- the requirements should be
written down and some proposed solutions to the "RFC 2317 problem" offered.

i am not volunteering to write or edit, but i will act as a reviewer if this
gets traction, and ISC would very likely implement the result in BIND9.

paul

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>