Subject: Reminder -- [Mip6] WGLC: draft-ietf-mip6-bootstrapping-split-01 (Deadline is Nov 30, 05)

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 24 Nov 2005 15:52:19 +0100

Hi all,

no comments have been sent so far on draft-ietf-mip6-bootstrapping-split-01. 
Please review the draft and provide your feedback. The deadline is November 30th 2005.

Thanks,
--Gerardo 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Basavaraj Patil
> Sent: venerdì 4 novembre 2005 21.15
> To: [email-masked]
> Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-split-01 
> (Deadline is Nov 30, 05)
> 
> 
> 
> Hello,
> 
> This is a Working Group last call for the following I-D:
> I-D :draft-ietf-mip6-bootstrapping-split-01
> Title: Mobile IPv6 bootstrapping in split scenario
> 
> The status associated with this I-D is : Standards track
> 
> Please review and post your comments by November 30th, 2005.
> 
> -Chairs
> 
> URL to I-D:
> http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-
> split-01.txt
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Nov 2005 10:58:56 +0100

This is not a new comment but I still believe the DNS Update mobility option
(section 8.1) is not the right mechanism.

Regards

[email-masked]

---

From: "Junghoon Jee" <[email-masked]>
Date: Tue, 29 Nov 2005 11:53:31 +0900

Hello Francis,
Let me ask a question about your comment.
Do you have an issue of including DNS update function to the bootstrapping
solution?
Or do you think that we need any other mechanism to update DNS records
except using DNS update mobility option?

Sorry not capturing your comment immediately even if it's not new.  :-)

Thanks in advance,
Junghoon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francis Dupont
Sent: Monday, November 28, 2005 6:59 PM
To: Gerardo Giaretta
Cc: [email-masked]
Subject: Re: Reminder -- [Mip6] WGLC:
draft-ietf-mip6-bootstrapping-split-01(Deadline is Nov 30, 05) 

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 28 Nov 2005 19:16:03 -0800

see http://mip4.org/issues/tracker/mip6/issue49

Vijay

---

From: "Junghoon Jee" <[email-masked]>
Date: Tue, 29 Nov 2005 15:25:01 +0900

Thanks for refreshing my memory.  :-)

Trying to understand the exact discussion points from the issue tracker;

A discussion point about the security in updating DNS records: 
I have some similar concern here. The setting up security channel between HA
and DNS is not an easy stuff. Even if depending on the secure channel
between HA and AAA, we still need secure channel between AAA and DNS.
However, I can not find any brilliant way to amend the current texts. 

The other is about who's the right entity to update DNS records:
Even if some different opinions were there, I think same consensus of
depending on the home agent to actually update the DNS records. 
I would like to exactly understand the Francis's concern here...
Francis, are you suggesting that the usage of BU message is not required,
because this is just an indication for the mobile node's notification of
willingness to update to DNS records? Even if I have somewhat in line with
this observation, I think the Vijay opinion about its usefulness in case of
home address auto-configure is valid. 
Francis, are you only considering the case of stateful home address
configuration case, because the validation of stateless address is not
possible through this kind of DHCP like configuration case? 

BTW, aside from understanding the exact discussion points from the issue
tracker, I found some tight coupling between BU/BA processing and DNS update
procedure. Does the home agent have to wait to finish the DNS update
processing before sending BA? I think that this kind of tight coupling needs
to be avoided because the RFC 3775 compliant implementation must not be
interrupted owing to any problems related with DNS. I don't think this kind
of interruption of basic Mobile IPv6 operation is not the right direction to
proceed even with any good rationale.

---------------------------
Section 6. Home Address registration in the DNS:
"As soon as the Home Agent has updated the DNS, 
It MUST send a Binding Acknowledgement message to the Mobile Node 
including the DNS Update mobility option with the correct value in 
the Status field (see section 8.1)."
---------------------

Even if I am misunderstanding something here, I think some rewording or
clarification is required.

As a side note, I found editorial errors from Figure 3 and 4.
I think second BU meant BA. Any way, I am not in favor of this kind of tight
coupling.

Junghoon

---Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Tuesday, November 29, 2005 12:16 PM
To: Junghoon Jee
Cc: 'Francis Dupont'; 'Gerardo Giaretta'; [email-masked]
Subject: Re: Reminder -- [Mip6] WGLC:

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 29 Nov 2005 14:57:45 +0100

In your previous mail you wrote:

=> not even IMHO it doesn't belong to the core of the bootstrapping
solution, i.e., the DNS update function is a part of address allocation
and is in the bootstrapping only because the bootstrapping includes
an address allocation (the home address one)

=> we need to use a less dedicated mechanism.

=> I've seen a pointer to the issue in the tracker in another message.
   
Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 29 Nov 2005 15:36:54 +0100

=> the standard rule is to update only where you are trusted so
the MN should update the direct DNS and the HA (or the entity allocating
address on behalf of the HA) the reverse DNS. This is the way it is
done for DHCP and I can't see why the mobility is so special it has
to reinvent the wheel!

=> the one what has the trust to do it of course.

=> the update should be a consequence of the allocation of the address,
not of the home registration. A bad consequence of doing it the wrong
way is a security hole on the name: the mobility code has no proof
the given FQDN is the right one, in fact it should have no knowledge
about FQDNs...

=> no but if you speak about a kind of DHCP like configuration case I'd
like to know why the DHCP way to provide this function doesn't work
with mobility.

   procedure.

=> something which is not useful at all. The coupling should be between
the address allocation and the DNS update as usual.

   Does the home agent have to wait to finish the DNS update
   
=> so you should support me.

=> yes, this is a (pretty bad) consequence of the overloading of
home registration with DNS update.

Regards

---

From: "Junghoon Jee" <[email-masked]>
Date: Wed, 30 Nov 2005 01:29:14 +0900

=> not even IMHO it doesn't belong to the core of the bootstrapping
solution, i.e., the DNS update function is a part of address allocation and
is in the bootstrapping only because the bootstrapping includes an address
allocation (the home address one)

Let me share some history about including the DNS update function within the
bootstrapping solution.
Through the previous bootstrap DT discussions, I disagreed to include this
function in the bootstrapping solution.
Actually about 3 members did have same opinion with me. Several members did
like to include this.  :-) 
After the intensive discussion and conf. call, the DT made a decision to
include this DNS update function 
as an optional function of bootstrapping solution. 
Therefore, I have no objection to include this optional function to the
split bootstrapping solution.
However, I got to have an issue regarding how to update DNS records.

> => the update should be a consequence of the allocation of 
> the address, not of the home registration. A bad consequence 
> of doing it the wrong way is a security hole on the name: the 
> mobility code has no proof the given FQDN is the right one, 
> in fact it should have no knowledge about FQDNs...

> => yes, this is a (pretty bad) consequence of the overloading of home
registration with DNS update.

I think we, MIP6 WG has come up with new issue regarding "how to update DNS
records".
I first would like to express my apology not capturing this tight coupling
feature at more earlier stage.
However, I think I should say this concern needs to be hopefully resolved.

Thanks,
Junghoon