Subject: Re: RFC2136 and IP address ownership

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 6 Dec 2005 11:50:54 +0100

Hello Alper,

I have CC-ed  namedroppers on my reply. There is quite some  
collective history there.

My "no-hats" reply is below, I am sure there are colleagues that will  
correct me when I am wrong.

--Olaf

On Dec 5, 2005, at 23:22 , Alper Yegin wrote:

> Dear DNSEXT WG chairs,
>
>
>
> As part of the Mobile IPv6 Bootstrapping solution (*), the MIP6 WG  
> is discussing “IP address ownership” issue around the use of RFC2136.
>
>
>
> When an IP address is dynamically assigned to a mobile node, there  
> needs to be a dynamic update to the DNS using RFC2136.
>
>
>
> We’d like to ask your and DNS community’s opinion on one thing  
> though: IP address ownership issue.
>
>
>
> Isn’t a client registering some other node’s IP address as its own  
> via RFC2136 an issue? RFC2136 does not seem to care about this “IP  
> address ownership” issue. Was this ever considered? Is there any  
> new work/discussions on this matter?
>
>
>
> Regards,
>
>
>
> Alper
>
>
>
> (*)
>
> http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-03.txt
>
> http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping- 
> split-01.txt
>
>

First an aside, "IP-ownership" is tricky terminology.  The DHCP  
community uses the term "lease" which, IMHO, better reflects that an  
IP assignment is not for infinity.

In general the DNS allows maintenance of certain zones to be  
delegated for technical managerial responsibility (which name servers  
serve the zone, reflected in the NS RR set) as well as the  
responsibility for the zones content (reflected through the SOA RR).

The "content manager" is responsible for the content of the zone and  
will therefore need to grant certain parties the authority to update  
the (reverse) DNS.

RFC2136 provides a hook for a client that has been granted authority  
to update content to actually add, delete and modify using the DNS  
protocol. RFC2136 uses "Primary Master" to describe which of the name  
servers can be used for content management. (reflected to the MNAME  
in the SOA). The authentication mechanisms used in this context are  
TSIG and SIG0 but the authorization is still a local policy, managed  
outside protocol. For one popular implementation the authorization is  
done through configuration files.

It is completely local policy to which client this authority granted.

So to answer the question:
> Isn’t a client registering some other node’s IP address as its own  
> via RFC2136 an issue? RFC2136 does not seem to care about this “IP  
> address ownership” issue. Was this ever considered?
Indeed, RFC2136 is completely ambivalent about the zone content and  
assumes that the authorization of who is allowed to update a certain  
zone is done "elsewhere".

Skimming the MIP6 draft I see a lot of parties involved; I have not  
read the drafts in enough detail to give sound input. Let me know if  
that is needed at this time.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Paul Vixie <[email-masked]>
Date: Tue, 06 Dec 2005 15:09:07 +0000

i have long thought that RFC 2136 ought to have recommended that implementors
support a "self" ACL, such that for some zones (likely, those full of PTR's)
could be set up so that the ability to do a three-way TCP handshake using a
given IP (or IP6) address would grant create/delete access to some set of RR
types (PTR, NAPTR, TXT, etc) at the names corresponding to the inverse address
node (so, for 192.5.5.241, that's 241.5.5.192.in-addr.arpa).

RFC 2317 complicates this goal considerably.  without a solution that allows
for pattern matching with arbitrary intermediary zone names, a "self" ACL is
not useful.  if your parent zone delegates using a $GENERATE CNAME, then you
have to have a way to express to your "self" ACL logic which octets/nibbles
of the address are to be built up out of labels that might include _ or - or
/ or \. (literal period) or any of the other things RFC 2317 users might use.

if someone wants to take this on, i'd be grateful and i suspect that the MIP6
WG and other WG's would also be grateful.  microsoft offered GSS-TSIG as their
solution to "too many nodes with update permission to be able to distribute
TSIG keys to all of them", but GSS-TSIG is a big mouthful of code and RTT for
something as trivial and frequent as a mobile-IP device, which could be "thin",
crossing a cell boundary.

i apologize for not encoding what i knew about this problem space as a "NOTE"
or "CAVEAT" in RFC 2136.

on the plus side, a new specification on this topic would not invalidate any
part of RFC 2136.  something is currently missing, but nothing is currently
wrong.

--
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 18:53:09 +0000

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

---

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

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

---

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

> 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

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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: Francis Dupont <[email-masked]>
Date: Wed, 07 Dec 2005 00:41:31 +0100

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.

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. The problem is without a DHCPv6 server
all nodes have to update the reverse tree themselves and they are
not authorized to do it.

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.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Dec 2005 00:42:55 +0100

Regards

---

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.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Dec 2005 01:29:34 +0100

In your previous mail you wrote:

   I can briefly describe whats in the draft. what we have done so
   far is to let the home agent do the update (both direct and
   reverse tree)

=> I disagree: the draft says "the" DNS entry and it is clearly only
the direct tree.

   instead of the mobile node. this assumes the home
   agent is more trusted than the mobile node.
   
   the home agent knows both the FQDN of the mobile node (through
   IKEv2 authentication) and the home address of the mobile node
   (since it is involved in the home address bootstrapping).
   
=> this is not true for two reasons:
 - IKEv2 authentication gives the FQDN only in some cases, not in
   all cases
 - the IKEv2 code and the mobility code are 2 different entities,
   the DNS update in the draft is performed by the mobility code
   using the FQDN given by the mobile node in a mobility option.

   the mobile node is still in control because the home agent does
   not do the update until the mobile node indicates this in the
   binding update.
   
=> this mobility option has only a do-undo flag. The DHC DDNS work
shows that far more are needed.

   we just got around addressing the address ownership problem. :)
   
=> for a reason I can't understand some persons in the MIP6 WG are
convinced the security of dynamic DNS updates relies on the protection
of the RDATA more than on the protection of the NAME...

I give up, I have more interesting things to do, I'll only bash
the draft if it is not fixed before the IETF last call.

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Dec 2005 11:14:22 -0800

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

hi,

Olaf M. Kolkman wrote:

> community uses the term "lease" which, IMHO, better reflects that an  IP 
> assignment is not for infinity.
> 
> In general the DNS allows maintenance of certain zones to be  delegated 
> for technical managerial responsibility (which name servers  serve the 
> zone, reflected in the NS RR set) as well as the  responsibility for the 
> zones content (reflected through the SOA RR).
> 
> RFC2136 provides a hook for a client that has been granted authority  to 
> update content to actually add, delete and modify using the DNS  
> servers can be used for content management. (reflected to the MNAME  in 
> the SOA). The authentication mechanisms used in this context are  TSIG 
> and SIG0 but the authorization is still a local policy, managed  outside 
> protocol. For one popular implementation the authorization is  done 
> through configuration files.
> 
>> Isnt a client registering some other nodes IP address as its own  
>> via RFC2136 an issue? RFC2136 does not seem to care about this IP  
>> address ownership issue. Was this ever considered?
> 

I can briefly describe whats in the draft. what we have done so
far is to let the home agent do the update (both direct and
reverse tree) instead of the mobile node. this assumes the home
agent is more trusted than the mobile node.

Vijay

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 7 Dec 2005 09:54:31 +0100

> agent is more trusted than the mobile node.

And would the mobile node have an IP6 address on the access network  
(i.e. roaming far away from its home agent) for which it would need  
to update the reverse DNS?

My general thinking goes into the direction of SIG0 based  
authentication. I think that can be made to work but I need to  
understand the relation between the maintainer of the DNS in the  
forward tree(s), the maintainer of the DNS in the reverse tree, and  
the maintainer of the mobile agent, the mobile client and the  
networks involved.

Obviously you will need to store the client's public keys somewhere  
in the DNS, that could be a duty of the home agent during the  
bootstrapping phase. The maintainers of the several pieces of DNS  
namespace should then put trust into those keys.

This technology (SIG0 based dynamic updates of secured zones) works  
today.

And now I should really scheadule some time to read about the general  
MIP6 architecture, for now I am just thinking out loud, a bad  
practice :-)

--Olaf

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 07 Dec 2005 12:01:14 -0800

Olaf M. Kolkman wrote:
> (i.e. roaming far away from its home agent) for which it would need  to 
> update the reverse DNS?

no. the DNS update is only for the home address. and the
home address is allocated from the home link.

Vijay

> forward tree(s), the maintainer of the DNS in the reverse tree, and  the 
> maintainer of the mobile agent, the mobile client and the  networks 
> involved.
> 
> Obviously you will need to store the client's public keys somewhere  in 
> the DNS, that could be a duty of the home agent during the  
> This technology (SIG0 based dynamic updates of secured zones) works  today.
> 
> MIP6 architecture, for now I am just thinking out loud, a bad  practice :-)
> 
> --Olaf
>