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

[Paul Vixie <paul@vix.com>]

# > 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.
# 
# Key compromise wasn't what I was talking about.  The case is an end node
# with a perfectly legitimate key that decides to launch a redirection attack.
# The attack could be deliberate, for example, a user with a legitimate
# account establishes a security association but launches the attack for some
# reason (for example, the victim is an ex-spouse in the middle of a contested
# divorce proceeding and the attacker wants to harrass him/her), or it could
# be inadvertent, for example, the end node is infected with a virus or
# spyware.  I think only the latter could be considered a key compromise.

i think i got your meaning the second time here.  basically you're saying that
the "self" ACL, with whatever tricks needed to work with RFC 2317, is still
nec'y because otherwise we'll have to protect individual DNS names with unique
keys per host, which won't scale.  hmmmm.  i wonder how microsoft's GSS-TSIG
works around this?  (possibly by just outlawing RFC 2317 for ancestor zones,
or by requiring a certain label syntax rather than leaving it to user choice?)

i agree that the security considerations section of any resulting specification
ought to have words to the effect that "in no case should an end-node have the
ability to update DNS names nearby but not equal to those needed for its own
IN-ADDR registrations".

# > 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.
# 
# Well, that is the approach we've recommended in
# draft-ietf-mip6-bootstrapping-split-01.txt (i.e. let the home agent do the
# update), but we are running into headwind from some WG members who claim
# that this "isn't a MIP6 WG problem" and "we should let the DNS community
# solve the problem". I suppose we ought to pole the DHC WG and find out if
# Yakov's suggestion has become current practice or not. I notice that their
# WG draft on DNS update for DHCP assigned addresses
# (draft-ietf-dhc-fqdn-option-11.txt) has provisions for both host and server
# update.

it's a very subtle situation.  after a successful DHCP assignment or expiry,
two DNS names have to be updated, the "forward" (having A or AAAA RRs), and
the "reverse" (having PTR RRs).  of course, both can also have other RR
types such as TXT for e-mail source security or whatever.)  anyway, the
"forward" name is the one most dhcp clients are likely to have a TSIG key
for (or a GSS-TSIG relationship, or whatever).  the "reverse" zone is the
one the dhcp *server* is likely to have a TSIG key (or whatever) for.

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