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

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Dec 2005 09:35:17 +1100

> # > 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.

	For RFC 2317 style zones I suspect they will need to know the prefix
	and range by some out of band mechanism and how the non prefix bits
	map into the owner-name.

	Off the top of my head this would be how I would implement it for
	BIND.

	e.g.
	allow-update {
		self 1.2.3.128 1.2.3.200 "${4}.128-200.3.2.1.in-addr.arpa";
	};

	And the general case for the non RFC 2317 style reverse zone.

	allow-update {
		self 0.0.0.0 255.255.255.255 "${4}.${3}.${2}.${1}.in-addr.arpa";
	};

>  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".
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 06 Dec 2005 22:49:22 +0000

# > 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.
# 
# 	For RFC 2317 style zones I suspect they will need to know the prefix
# 	and range by some out of band mechanism and how the non prefix bits
# 	map into the owner-name.

i'd rather do it by looking at the dns data itself.  that is, following the
CNAME chain if any, starting from a qname computed based on the transport
and ip/ip6 address.  what "self" should mean is that if they want to update
what the cnames point to, that should be allowed.  unfortunately this would
require perfect trust in the ancestor zones, and would be totally irrational.

# 	Off the top of my head this would be how I would implement it for
# 	BIND.
# 
# 	e.g.
# 	allow-update {
# 	    self 1.2.3.128 1.2.3.200 "${4}.128-200.3.2.1.in-addr.arpa";
# 	};

gaaaaaaaaaak.

# 	And the general case for the non RFC 2317 style reverse zone.
# 
# 	allow-update {
# 	    self 0.0.0.0 255.255.255.255 "${4}.${3}.${2}.${1}.in-addr.arpa";
# 	};

well, first, i don't think permissions can be given out of band unless we
update RFC 2136 to outlaw update forwarding.  (which BIND doesn't support,
but i suspect other implementations do support, and some people depend on.)

this yields a general sense that a thing that looked like $GENERATE would
be the right thing.  except that it has to be an RR, probably an ACL RR at
the apex.  (ACL RRs have been proposed several times over the years, and an
early version of similar technology was in older versions of BIND.)

if i'm right that it should be in-band, then it *is* an interoperability
concern and it *must*be* done by IETF rather than by each implementor ad-hoc.

and second, BIND's ACL syntax should remain generalized.  "self" is something
that a zone (either in band or out of band) has to define, and which ACL's
can then depend on.  so "self" would be a zone-level directive (or in-band
zone data, if update forwarding has to be able to work), and then "self"
would be a macro that was available inside the allow-update directive.  but
this is namedroppers; i'd rather discuss on bind-workers or bind-forum the
specific BINDisms needed to make something like "self" work inside BIND.  on
namedroppers we should only discuss implementation-independent issues.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Dec 2005 10:19:54 +1100

While it is true that update forwarding hides the identity
	of the client.  One could concieve a TSIG extention which
	allows a forwarder to add a TSIG it a unsigned request in
	which the other data is the address of the client.  This
	would be stripped on return.  TSIG errors would be translated
	to NOTIMP on return.

	Alternatively a forwarder could return NOTIMP for non-signed
	requests forcing the client to go directly.

	Mark

---

From: Paul Vixie <[email-masked]>
Date: Wed, 07 Dec 2005 00:04:30 +0000

# Note you talk about the IP address ownership for updates in the reverse
# tree when the issue in the MIP6 WG context is about updates in the
# direct tree, i.e., the address is the RDATA and not the NAME.

this i did not know.  clearly the problem must be broader than i'd thought.

# To come back to IPv6 and dynamic DNS update, DHCPv6 is not commonly
# used for the address management because the stateless autoconfig
# (RFC 2462) is far simpler.

there is a growing movement of operators away from EUI64 addressing.  i
spoke on this topic at a recent NAV6TF meeting.

# A possible solution is to use CGAs (RFC 3972) which provide a nice proof of
# ownership on the interface ID (low 64 bits of addresses).  IMHO this should
# be better than to rely on some kind of return routability check. The crypto
# part (RSA signature) is not a problem for a DNS software already supporting
# DNSSEC.

if heavy weight protocols are available and appropriate for cell boundary
crossings, then GSS-TSIG will probably serve, and all of this is moot anyway.