Subject: [Mip6] Concensus Call: DNS Update for Bootstrapping

From: "James Kempf" <[email-masked]>
Date: Mon, 5 Dec 2005 10:51:27 -0800

We have had some discussion on the issue of including DNS update in the MIP6 
bootstrapping specification. The authors would like to call for working 
group opinions about whether and how to include DNS update into the 
bootstrapping draft.

Reading through the commentary, the following three proposals seem to have 
come up;

1) Say nothing about DNS update. Take the issue to the DNS community, where 
a specification could be done somehow.

2) Specify a DNS update mobility option for MIP6, as described in the 
bootstrapping draft, and have the HA do the update. Tighen up the 
specification of address authorization so that it is implementable.

3) Specify a DNS update CFG option for IKEv2, and have the IKEv2 responder 
do the update. Ensure that address authorization is tightly specified enough 
to be implementable.

Please indicate in your reply whether you favor 1), 2), or 3). We'll run the 
concensus call for about 2 weeks, until Dec. 20.

            jak 

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

---

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

Jim,

I have issues with option 1). its not an option.

one of the main features of MIP6 is IP reachability
at the home address. when the MN bootstraps a HoA,
it is no longer reachable at the new HoA. so the
MN's DNS entry MUST be updated. otherwise the
bootstrapping solution we design is not complete.
how do the update is what we should discuss here.

there are two options.

1. have the MN do the update
2. have the HA do the update

both the above options uses RFC 2136. No new DNS
update mechanisms are required.

I think extending IKEv2 is a non-starter too. it
does not make sense to keep extending IKEv2. and we
do want to use IKEv1 and the authentication option
protocol in some cases. IMHO, option 3 might be out
too. FWIW, in 3GPP2, the authentication option
protocol is used with the HA doing the DNS update
on behalf of the mobile node. see the "IP
Reachability" section in release D.

Vijay

James Kempf wrote:
> We have had some discussion on the issue of including DNS update in the 
> MIP6 bootstrapping specification. The authors would like to call for 
> working group opinions about whether and how to include DNS update into 
> the bootstrapping draft.
> 
> Reading through the commentary, the following three proposals seem to 
> have come up;
> 
> 1) Say nothing about DNS update. Take the issue to the DNS community, 
> where a specification could be done somehow.
> 
> 3) Specify a DNS update CFG option for IKEv2, and have the IKEv2 
> responder do the update. Ensure that address authorization is tightly 
> specified enough to be implementable.
> 
> Please indicate in your reply whether you favor 1), 2), or 3). We'll run 
> the concensus call for about 2 weeks, until Dec. 20.
> 
>            jak
>

---

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

1) because 2) is not the right place and 3) is out of the scope of
the WG (but we should send it to the IPsec WG).
BTW this concensus call should be posted to DNS and IPsec mailing lists too!

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 05 Dec 2005 23:42:10 +0100

In your previous mail you wrote:

   one of the main features of MIP6 is IP reachability
   at the home address. when the MN bootstraps a HoA,
   it is no longer reachable at the new HoA. so the
   MN's DNS entry MUST be updated.

=> I disagree with the MUST because it relies on two missing
details:
 - the MN wants to be reachable using its FQDN (i.e., it is a server)
 - the HoA is really dynamic
note these two properties are usually incompatible because of the DNS
caching.

   otherwise the bootstrapping solution we design is not complete.
   how do the update is what we should discuss here.
   
=> to put the issue in the scope of the MIP6 WG you have to prove
the home address is special, i.e., the standard solution for a
standard address cannot work. I've never seen a word about this.

   there are two options.

=> you have to be more accurate: it is the update in the
direct tree (FQDN->IP) or the reverse tree (IP->FQDN).
I assume the first one.
The "HA" can be the mobility code or something else,
I assume again the first so there is a third option:
   3. have the address allocation facility in the HA do the update.

=> I've already explained what I think about this statement...

   I think extending IKEv2 is a non-starter too. it
   does not make sense to keep extending IKEv2.

=> I disagree: the issue exists outside the mobility context so
it has to be handled by IKEv2 (by an extention or something else).

   and we do want to use IKEv1

=> I can't see a real difference between IKEv1 and IKEv2 about this issue.

   and the authentication option protocol in some cases.

=> I refuse to discuss about the authentication option protocol.

   IMHO, option 3) might be out too.

=> option 3) is reasonnable: it has only a small problem: it is clearly
outside the scope of the MIP6 WG.

   FWIW, in 3GPP2

=> NO, PLEASE DON'T USE THIS KIND OF ARGUMENTS!!!

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Dec 2005 14:57:12 -0800

> note these two properties are usually incompatible because of the DNS

agreed. assuming the MN wants to be reachable at its FQDN,
the MN's DNS entry MUST be update when we bootstrap a HoA.

> direct tree (FQDN->IP) or the reverse tree (IP->FQDN).

yes. its the direct tree.

> => NO, PLEASE DON'T USE THIS KIND OF ARGUMENTS!!!

and why not? I work with 3GPP2 too, which happens to like
and use Mobile IP.

Vijay

---

From: Vidya Narayanan <[email-masked]>
Date: Mon, 5 Dec 2005 20:56:38 -0600

I'm just catching up with all the emails here - and, I am not even
sure where to start :) So, instead of replying to each of the mails,
I'm going to try to summarize my thoughts in this one email.

I think there is a misunderstanding of what I am saying - I am
not really *in* the debate of whether this work should be done in mip6
or dns or dhc. I do, however, think that it can be left out of the
bootstrapping draft. The main reason I'm saying this is the draft
currently (at least in my mind) doesn't seem to be clear on this
subject and I am not convinced that it is solving the security issues
correctly. It seems
bizzarre to say that FQDN ownership is not an issue, but address
ownership alone is - I say this without getting into the discussion of
whether it is 2136 or this draft that has an issue.

The issue really is not much different from a host obtaining an IP
address via DHCP doing a DDNS update. Even though this is debatable, I'll agree
that a DDNS update for the HoA is likely to be important for IP reachability. It
would be better left for a separate draft. Perhaps, a separate draft
on performing DNS updates for a mobile node can be done in
collaboration with the DNS community and can clearly provide a
view of what it is solving and securing and what it isn't.

The topic of auth option protocol keeps coming up - this draft does
not provide bootstrapping solutions for the auth option protocol. That
work is yet to be done. In fact, I thought it wasn't even in the scope
of the design team to do that work. If we are talking about the auth
protocol, I think there is a lot more to discuss here than just DNS.

However, using the same argument, I believe that the DNS part of the
solution can be the same for both IKEv2 based bootstrapping and the
auth option bootstrapping - from both points of view, it seems better
to separate it out from individual bootstrapping solution drafts.

Does this make sense to anyone?

Thanks,
Vidya

---

From: Francis Dupont <[email-masked]>
Date: Tue, 06 Dec 2005 10:27:36 +0100

=> what is very unacceptable for someone not working with 3GPP2
is that one goes to the 3GPP2, standardizes a new thing which is
the scope of the IETF and comes back to the IETF saying this should
be blindly adopted because it was done by the 3GPP2!
Note this still stands when 3GPP2 is replaced by 3GPP or ETSI or...

Regards

---

From: "James Kempf" <[email-masked]>
Date: Tue, 6 Dec 2005 09:13:32 -0800

So do you support option 1), 2), or 3)?

        jak

----- Original Message ----- 
From: "Vidya Narayanan" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>
Cc: "Francis Dupont" <[email-masked]>; <[email-masked]>; 
"James Kempf" <[email-masked]>
Sent: Monday, December 05, 2005 6:56 PM
Subject: Re: [Mip6] Concensus Call: DNS Update for Bootstrapping

The issue really is not much different from a host obtaining an IP
address via DHCP doing a DDNS update. Even though this is debatable, I'll 
agree
that a DDNS update for the HoA is likely to be important for IP 
reachability. It
would be better left for a separate draft. Perhaps, a separate draft
on performing DNS updates for a mobile node can be done in
collaboration with the DNS community and can clearly provide a
view of what it is solving and securing and what it isn't.

Thanks,
Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Dec 2005 10:54:26 -0800

> whether it is 2136 or this draft that has an issue.

the idea is simple. instead of the mobile node doing the
DNS update as envisioned by the DNS community, we have the
HA do the update. no new DNS update mechanism. we still
keep the mobile node in control by having the mobile node
indicate in the BU that it wants the update to be done.

FQDN authorization is out of scope.

IMO, this is explained clearly in the draft. if not the
draft can be clarified as you want. which part of the draft
is not clear?

> view of what it is solving and securing and what it isn't.

nope. we already have too many drafts for MIP6 bootstrapping.
it becomes a mess when somebody tries to implement all
the stuff. so far there are potentially 9 drafts if we talk
about a complete MIP6 bootstrapping solution.

1. bootstrapping with IKEv2
2. bootstrapping with IKEv1
3. bootstrapping with the authentication option protocol
4. bootstrapping with DHCP
5. DHCP options for bootstrapping
6. bootstrapping problem statement draft
7. HA-AAAH interface goals document
8. RADIUS extensions to support NAS-AAA and HA-AAAH interfaces
9. Diameter extensions to support NAS-AAA and HA-AAAH interfaces

> protocol, I think there is a lot more to discuss here than just DNS.

the design team consensus was that it is out of scope. it
will be an individual draft. it will be out soon.

> Does this make sense to anyone?

you havent actually explained what is not clear in the
split bootstrapping document. we can clarify that.

Vijay

---

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

> Note this still stands when 3GPP2 is replaced by 3GPP or ETSI or...

I should have made it clear. in this particular case
3GPP2 did not ask us to standardize their DNS update
solution. they have used this release B or something
like that.

I showing that as an example where they didnt try to
provision security between each mobile node and the
DNS server. its a pain. instead they just have the
HA or AAAH do the DNS update.

Vijay

---

From: Vidya Narayanan <[email-masked]>
Date: Tue, 6 Dec 2005 15:30:05 -0600

I'd have to say 1 at this point, since there is no option 4 that says
keep it out of specific bootstrapping solutions drafts and do a draft
in conjunction with the DNS community on the topic.

Vidya

---

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

In your previous mail you wrote:

   > It seems
   
   the idea is simple. instead of the mobile node doing the
   DNS update as envisioned by the DNS community,

=> I have to say the DNS community knows more about the DNS than
the MIP6 community.

   we have the

=> for the DNS community the FQDN authorization is the critical point
for a dynamic DNS update in the direct zone.

=> IMHO it is pretty clear the draft is fully wrong about this point
so should be fixed ASAP or be dropped at the IETF last call
(of course I prefer the first option :-).

=> of course, the MIP6 WG is trying to redesign the whole Internet
so it can't be done in some lines (:-).
BTW I agree few good proposals is better than plenty of junk proposals.

   so far there are potentially 9 drafts if we talk
   about a complete MIP6 bootstrapping solution.
   
=> I disagree about your intented meaning of "complete".

=> if you have to keep one, it should be this one because it can solve
all the problems (including now HA assignment).

=> I don't believe to twist IKEv1 to do more than it can today is a good
idea: IKEv2 is so better.

=> IMHO we should do standard track stuff before, at least at the IETF.

=> do you refer to the 3rd bootstrapping document (integrated scenario)?

=> 5 is included into 4.

=> this is not a solution document (BTW it is still useful)

=> these are in fact at most one document.

So I can see at most 4 documents which cover what we already have into
the current 3 documents... So I don't buy your argument.

   
=> the document is not unclear, it is wrong. What is not clear
is if you have understand what we believe is wrong and if you are
ready to fix it or just to say the DNS is wrong and has to be fixed.
Note that in the second case you may have your own opinion, the issue
is this is not the right place to discuss it.

Regards

---

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

DNS server. its a pain.

=> I don't understand why mobile nodes can't use TSIG or SIG(0)
as all the nodes using dynamic DNS updates today do. BTW I don't
understand too why it is not possible to use static interface IDs
and no dynamic DNS update: this is not for a privacy reason because
home addresses are published...

Regards

---

From: Vidya Narayanan <[email-masked]>
Date: Wed, 7 Dec 2005 18:06:13 -0600

> draft can be clarified as you want. which part of the draft

The draft states:

"Since the DNS update must be performed securely in order to
        prevent attacks or modifications from malicious nodes, the node
        performing this update must share a security association with the
        DNS server..."

And then states:

"Therefore, due to security and administrative reasons, it is
        RECOMMENDED that the Home Agent perform DNS entry update for the
        Mobile Node...."

This is misleading. You are not solving the above problem of generally
protecting against all malicious nodes. You are specifically solving
the problem of "a node being trusted to provide the right FQDN
providing the wrong HoA". The definition of a malicious node is really
much broader and can be subject to interpretation.

Even in section 9.5, the draft talks about the fact that FQDN
ownership can be taken care of with DNSSEC, while address ownership
can't. It fails to mention that with the HA performing the DNS update,
it is the exact reverse - while address ownership is taken care of,
FQDN ownership isn't. I think it should be clearer that we cannot get
FQDN *and* address ownership if that was needed.

> about a complete MIP6 bootstrapping solution.

Whether it is the 9 documents listed below or a shorter list as
Francis says, I am sorry to say that this seems to be taking the
doomed path of IKEv1. The kind of cross references we will have here
is going to be bad. (Not to mention that boostrapping mip6 technically
doesn't compare in complexity to IKE in any dimension!!). Also, we
shouldn't say "bootstrapping with IKEv2" if parts of that document are
meant to be a base document that other bootstrapping documents will
refer to.

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 07 Dec 2005 16:55:41 -0800

> much broader and can be subject to interpretation.

sure. but we should solve specific problems instead of
taking on everything you want.

> FQDN *and* address ownership if that was needed.

again, you missed the assumption that the HA is more trusted
to the DNS server than the mobile node.

> doomed path of IKEv1. 

how did you arrive at that conclusion? for IKEv1, you needed
to implement a bunch of drafts to have the complete solution.
with MIP6 bootstrapping I hope nobody implements all the
drafts. that would never be needed. :)

> Also, we

whats wrong with that?

Vijay

---

From: Vidya Narayanan <[email-masked]>
Date: Thu, 8 Dec 2005 10:25:00 -0600

> taking on everything you want.

Fine. But you should state the specific problem you are solving and
the problems that exist, but are considered outside the scope of the
document. Assuming that a certain problem is more important than a
certain other problem doesn't make sense to me.

.
> to the DNS server than the mobile node.

A paranoid customer (and I've dealt with a few of those) is going to
want to provide both FQDN and address ownership checks. A paranoid
customer is likely to consider DNSSEC in the bigger picture. With the
introduction of mip6, if we are saying that one has to pick between
achieving FQDN authorization and address authorization, such customers
will find it unacceptable. Providing a way to solve both is not
impossible, but rather painful.

So, all I am saying is that what is lost by the HA performing the
update must be stated - if you want to add the fact that it has been
assumed that the HA is more trusted, that is fine.

> drafts. that would never be needed. :)

True. But, putting myself in the shoes of implementors who aren't on
this list, who aren't aware of the history of documents, it is a pain
to have a situation where you have 9 documents, some of which
reference parts of other docs for a complete solution. It is much
simpler to say that the common elements are specified in one document
and the variables in  bootstrapping are separate drafts. Anyway, it is
not an issue for people like myself, so, I won't spend more time on
this :)

> > meant to be a base document that other bootstrapping documents will

Just misleading, when parts of the document have nothing specifically
to do with IKEv2.

Vidya

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 8 Dec 2005 18:48:04 +0200

> not an issue for people like myself, so, I won't spend more time on

The issue of # of documents were raised during the DT discussions. My
personal view is, I'm not bothered by # of documents, as long as there
is enough guidance on how to put them together like Lego pieces. That
can be provided by framework/architecture documents. On the other hand,
unless absolutely necessary and "atomic", I rather not bundle multiple
protocol extensions (IKEv2, DHCP, MIP6, etc.) into single document for
the sake of document reduction. 

Alper

---

From: "James Kempf" <[email-masked]>
Date: Thu, 8 Dec 2005 08:48:10 -0800

Vidya,

Regarding the wording describing the motivation for HA update, if you don't 
like the wording, then please provide some alternative. The intent of this 
discussion is to converge onto a document that we can, with some amount of 
confidence, say is the rough concensus of the WG. On the other hand, if you 
don't like the general idea of having the HA do the update, then please 
express your preference in the concensus call and consider refraining from 
detailed comment about the wording.

Regarding the number of documents, the basic problem is that the IETF has 
failed to keep current with its document technology. IETF still uses a 
document representation format from the 1970's that does not support 
hyperlinks. This makes it difficult for people to actually gather the 
necessary information about dependencies. Given this, the DT decided as a 
compromise to put all the protocol bits needed for bootstrapping for IKEv2 
in the split scenerio in one document, including those that might be common 
to the other scenerios (since the split scenerio was the first document the 
DT wrote). Other scenerios, such as integrated, IKEv1, etc., are in 
different documents. This still results in an uncomfortable number of 
documents necessary for someone who wants to understand how to do 
bootstrapping across all the scenerios, but the division is along the lines 
of expected implementation "packages" (i.e. integrated scenerio with DHCP), 
with pointers back to the split document for functions that are common to 
all scenerios (i.e. IKEv2 home address assignment).

If IETF had a full up, hypertext-based document representation system, we 
would not have had this problem. We could have structured the entire set of 
documents with a top level page containing background information on 
bootstrapping and an outline of the general architecture, with links to the 
packages, such as integrated scenerio with DHCP, then those documents could 
have links to specific protocol bits, like the DHCP option for Home Agent 
discovery. We could even have doled out the standardization effort to other 
WGs, like having the DHCP option standardized by the DHCP WG. Alas, we don't 
have such technology, so we need to do the best we can. I complained about 
this problem at the IAB Plenary in Paris, but, as usual, my complaint was 
blown off.

               jak

----- Original Message ----- 
From: "Vidya Narayanan" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 07, 2005 4:06 PM
Subject: Re: FQDN authorization and splitting drafts (was Re: [Mip6] 
ConcensusCall: DNS Update for Bootstrapping)

The draft states:

And then states:

Vidya

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 09 Dec 2005 03:07:13 +0900

Hi 

2). But this should be totally optional feature. (maybe move the
section to appendix). This shouldn't be only solution for DNS
update. MN can also udpate DNS by itself.

Although it seems DNS update is important for bootstraping, there is
no recovery mechanism when DNS update is failed. If there is no recovery 
mechanism, why you need error codes? Success/fail is enough.

Are there any discussion about DNS cache? If HoA is frequently
changed, it might be inconsistency in caches.

It's better that DT discuss this with DNS WG. I want to see the
feedback from DNS WG.

ryuji

At Mon, 5 Dec 2005 10:51:27 -0800,

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 08 Dec 2005 11:27:11 -0800

> certain other problem doesn't make sense to me.

the specific issues we are solving are clearly
mentioned in the document.

- redirection attacks by sending DNS updates for some
other mobile node's HoA.
- scalability. an operator having to setup security
between each mobile node and the DNS server.

let us know how we can improve the text if this is not
clear.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 9 Dec 2005 00:49:47 +0200

James,

> necessary information about dependencies. 

I couldn't understand this point when I first read about it during the
DT exchanges, and I still can't. It's just a matter of "labor" whether
you just click the mouse on a link, or you concatenate
"http://ietf.org/internet-drafts/" with [I-D name from the References
section] and plug into your browser and hit the enter key. This
shouldn't be that bad to lead people to merge documents instead of
referencing them......

> would not have had this problem. We could have structured the entire
set
> of
> bootstrapping and an outline of the general architecture, with links
to
> the
> WGs, like having the DHCP option standardized by the DHCP WG. 

Well, aren't we doing that already? DHCP options are in a separate
document, draft-jang-dhc-haopt-01.txt, for the standardization of DHC
WG.

Alper

---

From: "James Kempf" <[email-masked]>
Date: Thu, 8 Dec 2005 15:08:06 -0800

> shouldn't be that bad to lead people to merge documents instead of

Have you ever used a good hypertext documentation system, like Microsoft's 
MSDN, when doing program design and development? The amount of cognitive 
load is far less if you can simply click through on a hyperlink to find a 
reference. Sure, it's possible to use full text search, but that's kind of 
what the Web was like before HTTP (Gopher and FTP files). Using a Web 
browers is a lot simpler. Of course, this is a matter of opinion, and I'm 
sure you'll disagree.

> document, draft-jang-dhc-haopt-01.txt, for the standardization of DHC

That's because draft-jang was already there. But when it came to the 
defining the DHCP Relay Option, we put that into 
draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt because there isn't any 
draft for it, right?

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 08 Dec 2005 19:00:42 -0800

> document, draft-jang-dhc-haopt-01.txt, for the standardization of DHC

nope, that was never decided conclusively. I still think
the DHCP options should be folded in the integrated
bootstrapping document.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Fri, 16 Dec 2005 11:02:28 -0800

I am in favor of keeping FQDN update in the split draft with the HA. Since 
it is a MAY, it is not Required to Implement, and therefore can be left out 
for implementations that just want to support host initiated FQDN update and 
are not concerned about address authorization checking. I think the HA 
SHOULD also update the reverse DNS record. I personally don't believe that 
many deployments will use this, because many ISPs don't actually deploy 
reverse DNS, but I believe it should be there for those that do.

I certainly have no objection if the DNS WG wants to work on the problem of 
address authorization checking for dynamic DNS, but I believe a solution is 
needed now for secure update of the FQDN in order to best support MIPv6 
deployment. If it turns out that the DNS WG comes up with a good solution 
and HA-based update is not widely implemented, then the MIP6 WG can EOL 
HA-based update when the draft goes to Draft Standard.

            jak