Subject: Re: [Mip6] Comments on draft-ietf-mip6-bootstrapping-split-01.txt

From: Francis Dupont <[email-masked]>
Date: Thu, 01 Dec 2005 13:53:13 +0100

In your previous mail you wrote:

   >    if the MN has some other mechanism to update the DNS
   >    entry without involving the HA, all it has to do is
   >    to exclude the DNS update option in the BU. the
   >    problem is that we dont have scalable and secure
   >    mechanism today without involving the HA.
   >    
   > => we have RFC 2136 which is used everyday and is scalable and secure
   > for the direct tree. 
   
   well, AFAIK, RFC 2316 is not practical when you have a
   lot of mobile nodes that want to update their DNS entries
   from visited networks. you have to setup security between
   each mobile node and the DNS server.

=> I fully disagree. RFC 2136 is practical when you have a lot of
nodes that want to update their DNS entries from networks they are
attached to. You have to setup security between each node and
the DNS server (and we know how to do it for the direct tree).

   it is easier for the HA to do the DNS update on behalf of the
   mobile node.

=> it is easier for the entity which controls the address allocation
for the reverse tree.

   and you still have the problem of the mobile node proving
   to the DNS server that it actually owns the address and
   is not setting up a DNS entry for some other mobile node's
   home address.
   
=> this problem doesn't exist and is not addressed in RFC 2136
so it is clearly an overkilling.

   > BTW the term "involving the HA" is not accurate enough, I believe you
   > mean involving the mobility code in the HA.
   
   correct. the MIP6 code on the HA.
   
=> so there is no reason to involve the HA if you don't want to redesign
a DNS dynamic update and not use the RFC 2136 one.

Regards

[email-masked]

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "James Kempf" <[email-masked]>
Date: Thu, 1 Dec 2005 09:27:28 -0800

Francis,

> so it is clearly an overkilling.

I know you don't believe in the value of return routability checks because 
you believe that if all ISPs deployed ingress filtering, redirection attacks 
would not be a problem. While I agree with you that, in an ideal world, 
ingress filtering would solve this problem, in the messy practical world 
that we live in, there will always be ISPs who won't and you can be sure 
that the attackers will seek out those ISPs if we don't build protection 
into the protocols. Unless there is some legal or regulatory solution (that 
is, ISPs get heavy fines or thrown in jail if they don't deploy ingress 
filtering), I don't see any other way to solve the problem.

In case you don't believe this, as a data point, I had a hallway 
conversation in Vancouver with a very prominant IETFer who once worked at a 
very responsible position with a large ISP, in which this person argued 
quite persuasively that ISPs shouldn't be required to deploy ingress 
filtering because it was up to the hosts to check addresses. I'm not quite 
sure if the person was serious, but it indicates the extent of the problem.

Currently, there is no way to do return routablity checks with DDNS if end 
hosts do update, in fact, it was not even recognized to be a problem when 
DDNS was developed in 1997. The DNS community is still in denial about the 
problem today. During the DT discussions, I queried members of the DNS 
community and was assured that no host would ever lie about its address when 
doing a DNS update. Sure, just like no email sender lied about its address 
in 1997 when DDNS was developed.

            jak

---

From: Francis Dupont <[email-masked]>
Date: Thu, 01 Dec 2005 19:17:00 +0100

=> note this case is very different: either the issue is serious and
the whole DNS must be fixed, including DNSSEC, because we trust
Microsoft to put the correct addresses for www.microsoft.com and not
the addresses of RedHat or another competitor. Or the issue is not
serious and we should keep the current DNS. Note that in any case
it is NOT in the scope of the MIP6 WG.

=> there is a thread about an attack against EDNS0 currently discussed
in a DNS mailing-list. The proposed solution is to use BCP 38 (:-)...
To come back about the way to enforce the ingress filtering IMHO
the best is to convince tier-1 to recursively do it.

=> as filtering the input traffic on the site boundary is not an effective
defense the only tools we have should be deployed in the middle, i.e.,
by the ISPs. So I don't believe the person was serious...

   problem today.

=> as a member of the DNS community I can understand why: the whole DNS
is based on trust: you are supposed to never publish a fake address and
the whole security (DNSSEC) is about to give a crypto proof the data
was not modified by an attacker.

   During the DT discussions, I queried members of the DNS community
   and was assured that no host would ever lie about its address when
   doing a DNS update.

=> note this is not in fact 100% true because some tools, including
old SunOS resolvers, check if the direct and reverse trees match.

   Sure, just like no email sender lied about its address 
   in 1997 when DDNS was developed.
   
=> PGP, S/MIME and many secure mail attempts were already available
far before 1997.

Interesting discussion but I am afraid it is fully outside the scope
of the MIP6 WG. BTW the MIP6 security is supposed to be not worse
than the current Internet... So about the split I-D I'd like the
DNS SRV RR (a possible improvment over the ICMPv6 DHAAD) but not
for unnecessary changes in IKE/DHCP/DNS/...

Thanks

PS: I believe you should crosspost your message in the namedroppers
list before going to IESG or IETF.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 1 Dec 2005 10:41:35 -0800

So you seem to be arguing that FQDN update for the MN isn't something that 
the MIP6 group should be doing, is that correct? If so, then I'd like you to 
explain how you see this as any different from a DHCP server updating the A 
and PTR records for a client? This functionality is described in 
draft-ietf-dhc-fqdn-option-11.txt which is a working group draft in the DHC 
Working Group. Clearly, the DHC Working Group thinks it is in their charter 
to specify how a client FQDN gets updated with a dynamically assigned 
address.

            jak

----- Original Message ----- 
From: "Francis Dupont" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>; <[email-masked]>; "Kilian 
Weniger" <[email-masked]>
Sent: Thursday, December 01, 2005 10:17 AM
Subject: Re: [Mip6] Comments on draft-ietf-mip6-bootstrapping-split-01.txt

---

From: Francis Dupont <[email-masked]>
Date: Thu, 01 Dec 2005 23:34:56 +0100

So you seem to be arguing that FQDN update for the MN isn't something that 
   the MIP6 group should be doing, is that correct?

=> yes, it should be a part of the home address allocation so it is
fine to mention it but it is not the job of the MIP6 group to design
a new mechanism to do it.

   If so, then I'd like you to explain how you see this as any
   different from a DHCP server updating the A and PTR records for a
   client?

=> it is not different at all as IMHO it should be the same thing,
i.e., it is a part in the "like" when we talk about a DHCP-like
mechanism.

   This functionality is described in 
   draft-ietf-dhc-fqdn-option-11.txt which is a working group draft in the DHC 
   Working Group. Clearly, the DHC Working Group thinks it is in their charter 
   to specify how a client FQDN gets updated with a dynamically assigned 
   address.
   
=> yes, I've proposed from the beginning to follow what is done by
the DHC WG which has years of experience about dealing with this...

BTW as the MIP6 has chosen to rely on IKE to provide a home address
allocation facility, directly or indirectly, I can't see why the
MIP6 WG should not rely on IKE, i.e., on IPsec WG, to deal with
this part of the address allocation facility. Don't forget the
IPsec WG has to provide solutions to the market and these solutions
could be more secure than usual because IKE could get stronger
authentication and authorization for the address and the FQDN.

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 Dec 2005 15:48:43 -0800

Francis,

you are forgetting one more thing. we eventually
want bootstrapping mechanisms for IKEv1 and the
authentication option protocol also. we cant make
everything too specific to IKEv2.

FWIW, I dont think we should mandate that IKEv2
should perform proxy DAD or that IKEv2 should
perform DNS update. sorry, but I cant agree with
you on this.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Fri, 02 Dec 2005 10:26:04 +0100

=> even if the IKEv1 document failed to provide a working
solution this doesn't mean there is no possible solution.
IMHO a solution will be even more DHCP-like than for IKEv2.
I'll not comment the authentication option protocol...

=> I agree if the "we" here is the MIP6 WG as it will
be outside of its scope.
What we (the MIP6 WG) should specify is:
 - the proxy NDP, including the proxy DAD, should be
   provided by the mobility code following the RFC 3775
 - as a server MN needs to publish its FQDN<->dynamic address
   mapping, the DHCP-like allocation facility should provide
   at least IP->FQDN registration in the DNS
The first one is to handle the mobility special case (in fact
only because in this case the MN can move so can come back to
the home link). The second is common sense but it seems there
is a consensus to explicitely mention it.

So I am against:
 - mandate something outside the scope of the WG, for instance
   that a client-server facility must provide a proxy NDP for
   the client at the server endpoint is just a fact
 - define a new mechanism in the mobility code for DNS registration

Regards

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 4 Dec 2005 00:31:01 +0200

> it is NOT in the scope of the MIP6 WG.

I had expressed the same concern during the DT discussions. Unless the
MIP6 WG accidentally happens to have the IETF's DNS expertise, we should
see the DNS* WGs make a statement on this issue, before each IETF WG
goes ahead with their own workaround. 

> The DNS community is still in denial about the problem today.

I think the MIP6 WG should run this by the "DNS community" before
embarking on a solution.

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Dec 2005 11:44:22 -0800

Alper,

> goes ahead with their own workaround. 

we dont define a new DNS update mechanism. RFC 2136 is used.
we just have the HA do the update instead of the MN. this
assumes the DNS server trusts the HA more than the MN. I
think RFC 2136 ignores the address ownership problem. Jim
did bring this up with some DNS folks. see Jim's email.

> I think the MIP6 WG should run this by the "DNS community" before

sure. we can refer the draft to the "DNS community". I ran
it by David Kessens when we first discussed this in the MIP6
bootstrapping design team.

but there is an important issue you are ignoring. one of the
main features of MIP6 is reachability at the home address.
when we bootstrap a HoA, this is lost. so we need to fix this.
I am not going to wait for the DNS community to first
recognize that there is a problem with DNS updates and then
come up with a solution. instead we have a simpler solution.
use the existing DNS update mechanisms, but let the HA do the
update instead of the MN. even here, this is completely
optional. if the MN can update the DNS entry by itself, it
can still do it. it does not have to use the mechanism in the
bootstrapping draft.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 5 Dec 2005 22:36:27 +0200

Hi Vijay,

> did bring this up with some DNS folks. see Jim's email.

I understood that. What I didn't understand was, why they thought this
was not a problem, whereas some "MIP6" WG members thought it was. There
is a disconnect. I think we shall understand the cause of this
disconnect. [Yes, at the end we may come back to the same end result.
But currently we are skipping obvious steps...]

> bootstrapping design team.

And what did he say?
 
> when we bootstrap a HoA, this is lost. so we need to fix this.

I understand that. That sounds reasonable.

> recognize that there is a problem with DNS updates 

Err, how come? It'd not make sense for others to devise workarounds to
what they claim to be issues with the "MIP6 protocol". Why should MIP6
WG do the same? 

Directly engaging in a conversation with the DNS community is a better
use of time than arguing about how we can solve this on our own.

Alper

> and then

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Dec 2005 13:08:00 -0800

Alper Yegin wrote:
>>>I had expressed the same concern during the DT discussions. Unless
> 
> the
> 
>>>MIP6 WG accidentally happens to have the IETF's DNS expertise, we
> 
> should
> 
> was not a problem, whereas some "MIP6" WG members thought it was. 

I dont know. I can only speculate, which I dont want
to. see Jim's email on this. BTW, I know a bit about
DNS too. its not like folks in the MIP6 WG have no
clue about DNS.

There
>>bootstrapping design team.

oh.. he didnt have any objections with this because we
are not really defining any new mechanism.

> Err, how come? 

for one, I think it would need a new return routability
check from the DNS server to the mobile node. probably
a new UDP message. this might by itself take a long
time to standardize. second, existing DNS servers might
understand RFC 2136, but not this new return routability
check. a simpler solution would be to use 2136, but have
the HA do the update. this would work with existing DNS
servers. again, we are defining a new solution. if
something else is available, we are can start using that
instead of having the HA do the update.

 > It'd not make sense for others to devise workarounds to

what issues? if there are issues with MIP6, we have
worked to address them quickly. or a new WG has been
spun off to handle stuff that MIP6 wasnt. for eg.
MIPSHOP, monami6, NEMO, etc...

> use of time than arguing about how we can solve this on our own.

we can do that too... but meanwhile we should fix
reachability at the home address when we bootstrap a HoA.
please start a discussion with the DNS community on the
address ownership issue. Jim already did this and thats
good enough for me.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Mon, 5 Dec 2005 13:33:17 -0800

Basically, the DNS community has not gone through the same discussion we 
have in the MIP6 WG (and also was done in Mobike) about address ownership 
proof and redirection attacks. Even if DNSSEC is used, a redirection attack 
is possible if the end host does dynamic DNS update, unless return 
routability or universal ingress filtering are deployed. The DNS community 
has not begun to grapple with this issue because, I think, dynamic DNS from 
the end host is not widely used today. If dynamic DNS update is done, it is 
done from the DHCP server since in IPv4, dynamic address allocation through 
DHCP is mostly universal.

The DHC WG has a draft in which they discuss multiple ways to do DNS update. 
One way is to have the DHCP server do it, but another is to have the host do 
it.  I guess I don't understand why the DHC WG can discuss this issue and 
write a standard for how to do it with DHC but the MIP6 WG can't. If we 
don't have a solution to this problem, then we lose a potential key 
technical point for achieving reachability with MIP6.

Can someone (Francis, Vidya, Alper) who is opposed to doing this in the 
bootstrapping draft explain to me why the DHC WG can specify a standard in 
this area for their protocol while MIP6 can't?

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Alper Yegin" <[email-masked]>
Cc: "'Francis Dupont'" <[email-masked]>; "'James Kempf'" 
<[email-masked]>; <[email-masked]>; "'Kilian Weniger'" 
<[email-masked]>
Sent: Monday, December 05, 2005 1:08 PM
Subject: Re: [Mip6] Comments on draft-ietf-mip6-bootstrapping-split-01.txt

---

From: Francis Dupont <[email-masked]>
Date: Mon, 05 Dec 2005 22:56:47 +0100

=> no, delegating the DNS update is to define a new DNS update
mechanism.

   we just have the HA do the update instead of the MN. this
   assumes the DNS server trusts the HA more than the MN.

=> despite the opposite as the DNS server trusts the owner of a name
more than anybody else.

   I think RFC 2136 ignores the address ownership problem. Jim
   did bring this up with some DNS folks. see Jim's email.
   
=> the whole DNS ignores the address ownership problem: the MIP6
WG should come back to places it is likely competent.

=> no chance!

=> you have no solution, only a likely flame war at the IETF last call.

=> the Padora'box lid is not optional.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 06 Dec 2005 00:26:22 +0100

the end host is not widely used today.

=> the address ownership issue is not an issue for the dynamic DNS update
but for the DNS itself. I can put any address I like into my DNS and
you have no way to stop me.

   If dynamic DNS update is done, it is done from the DHCP server
   since in IPv4, dynamic address allocation through DHCP is mostly
   universal.

=> this is true only for the reverse tree, for the direct tree
the client can perform the update itself and when it is nomadic
(cf. the "IPv6 nomadism == DHCP + DDNS" stuff which BTW was tried
at an IETF meeting :-) the client always performs the update in
the direct tree because the DHCP server can't.
   
   The DHC WG has a draft in which they discuss multiple ways to do DNS update.
   One way is to have the DHCP server do it, but another is to have the host
   do it.  I guess I don't understand why the DHC WG can discuss this issue
   and write a standard for how to do it with DHC but the MIP6 WG can't.

=> because it is not an entity specified by the MIP6 WG which provides
the address allocation. Note this is only by the choice of the MIP6 WG
but I guess I don't understand why this choice was done without taking
into account consequences...

   If we don't have a solution to this problem, then we lose a potential
   key technical point for achieving reachability with MIP6.

=> I believe you are trying to mix two different points: whether
dynamic DNS updates are useful in some cases in the bootstrapping scenario
and what is the entity which should do them.
The first point is arguable but I agree we should copy the DHC WG solutions
as there is nothing different between the DHCP and the bootstrapping
scenarios.
For the second point the split document says the entity in charge of
the allocation (i.e., playing the role of the DHCP server) is IKEv2
so IKEv2 should be in charge of the dynamic DNS update(s).

=> because the DHCP server-like entity is not a mobility entity in
any bootstrapping solution proposed by the MIP6 WG. More, this
DHCP server-like function in fact has nothing to do with mobility,
i.e., it can be (and is) used in contexts which has nothing to
do with mobility. 
This has an advantage: the MIP6 WG should not have
to reinvent the world, but this has a drawback: some parts of
the world will never be in the scope of the MIP6 WG (:-).

Note if the MIP6 WG designs a new mechanism where the home address
allocation is done by the mobility code itself the situation will
be different (but the update will be likely done before the BU)

Regards

---

From: "James Kempf" <[email-masked]>
Date: Mon, 5 Dec 2005 16:36:52 -0800

> you have no way to stop me.

Come on, Francis! The Security ADs aren't going to buy an argument like 
this. If we want to dynamic DNS update for Mobile IP to be approved by the 
IESG, regardless of whether MIP6 does it or someone else, the security 
issues need to be addressed. Either address ownership is an issue with 
dynamic DNS update or it is not (IMHO it is). If it is, it needs to be 
fixed. And since MIP6 needs this functionality, we need to figure out some 
way to get it specified.

> so IKEv2 should be in charge of the dynamic DNS update(s).

OK, so now I understand your technical point: the entity doing the address 
allocation should do the DNS update. If the address is allocated by the 
IKEv2 responder, it should do the update. Presumably also, if the MN 
autoconfigures the address via the IKEv2 responder providing the  prefixes, 
the MN should do the update?

> be different (but the update will be likely done before the BU)

OK, I think I understand your position now. Thanx.

            jak

                    jak

---

From: Francis Dupont <[email-masked]>
Date: Tue, 06 Dec 2005 18:40:33 +0100

this.

=> he should as I can easily prove this (I'll send the proof of list).

   If we want to dynamic DNS update for Mobile IP to be approved by the 
   IESG, regardless of whether MIP6 does it or someone else, the security 
   issues need to be addressed. Either address ownership is an issue with 
   dynamic DNS update or it is not (IMHO it is). If it is, it needs to be 
   fixed.

=> my main concern is this statement is outside the scope of the MIP6 WG.

   And since MIP6 needs this functionality,

=> any dynamic addressing can need this functionality. You argue
MIP6 is very special but I can't see why or how.

   we need to figure out some way to get it specified.

=> you are free to submit your arguments in a DNS mailing list.

=> when you read the right document (draft-ietf-dhc-dhcpv6-fqdn-03.txt)
you can see there are three options which, translated in our context, are:
 1. the MN updates the AAAA RR, IKEv2 responder updates the PTR RR
 2. IKEv2 responder updates both the AAAA and the PTR RRs
 3. the MN updates both the AAAA and the PTR RRs
They are ordered from the most to the less common, the last one (3)
is rare.

About the security, a RR has a left part "NAME" and a right part "RDATA".
To ask the ownership of the home address is to ask a security property
over the RDATA when what is important is to get a security property
over the NAME. This is why the option 1. is the prefered one because
as the MN owns its FQDN it is trusted to modify its AAAA RR. At the
opposite the IKEv2 responder and in general the entity which controls
address assignment is trusted to modify PTR RRs in the corresponding
reverse tree.
For the MN to prove the ownership of the address or for the IKEv2
responder to get a proof of the ownership of the FQDN by this
particular MN (BTW far easier to do in IKEv2 than in the mobility code)
is a good thing but should not at all being required as a DHCP server just
uses the FQDN given by the DHCP client trusting it to have provided
the right one (again cf. draft-ietf-dhc-dhcpv6-fqdn-03.txt).

Regards