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

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 01 Dec 2005 12:07:47 +0100

Hi Kilian,

thanks for your review. I'm splitting the editorial comments and the
technical ones. 

> 
> 
> Editorial
> =========
> 
> page 7 (end of page): 
> ---------------------
> - The last sentence "Figure 3 illustrates. " seems to be missing
> something
> 

I guess it does not miss anything. James wrote this sentence but I guess
it means that the figure illustrates what mentioned earlier.

> page 8:
> -------
> - "The split scenario is the simplest model that can be identified, 
> since no assumptions about the access network are made. "
> 
> 	s/"simplest model"/"most generic model" 
> 
> page 12:
> --------
> 
> - "Note that a 
> transport name cannot be used here because Mobile IPv6 does not 
> run   over a transport protocol. "
> 
> 	s/"run   over"/"run over"
> 
> - "The SRV RR has a DNS type code of 33. As an example, the Mobile 
> constructs a request with QNAME set to "_mip6_ipv6.example.com" 
> and QTYPE to SRV."
> 
> 	s/"_mip6_ipv6.example.com"/"_mip6._ipv6.example.com"
> 

fixed

> page 14:
> --------
> - "Generated Addresses (CGAs) [9] or based on the privacy extensions 
> for stateless autoconfiguration [10]. "
> 
> 	s/autoconfiguration/auto-configuration 
> ("auto-configuration" most used spelling in rest of document)
> 

fixed

> 
> page 17: 
> ----------
> - "For this purpose the Mobile Node MAY include a new 
> mobility option, the DNS Update option, with the flag R not set in 
> the Binding Update. 
> 
> 	This can be read as the R flag is in the BU, but it is in the
> DNS Update option (same on next page). 
> 

"
For this purpose the Mobile Node MAY include a new mobility option in
the Binding Update, the DNS Update option, with the flag R not set.
"

Sounds good?

> page 19:
> --------
> - Figure 3: I guess second BU should be BA
> 
> - Wrong figure numbering: Figure 3 already exist on page 8
> 

fixed

> page 20:
> --------
> - "Notice that, even in this last case, the Home Agent is always 
> required to perform a DNS update for the reverse entry, since this 
> is always performed in the DNS server of the MSP."
> 
> 	IMHO this should be stated earlier (in section 6), not in the
> "Summary of bootstrapping flow" section.
> 

I agree. I added the following sentence in section 6 (beginning of page
18)

"
Notice that, even in this case, the Home Agent is always required to
perform a DNS update for the reverse entry, since this is always
performed in the DNS server of the MSP.
"

Sounds good?

> - Figure 4: I guess second BU should be BA
> 

fixed

> page 22:
> --------
> - in the figure: "!R|         Attribute Type     !            Length
> | "
> 
> 	use "|R|         Attribute Type     |            Length
> | "  instead?
> 

good catch!

> - "Prefix Length (1 octet) - The length of the home prefix 
>            specified in the field Home Prefix. "
> 
>   use "Prefix Length (1 octet) - The length *in bits* of the home
> prefix..." instead?
> 

fixed

> 
> page 24: 
> --------
> - "Finally notice that assignment of an home agent from the serving 
> network access provider's (local home agent) or a home agent from 
> a nearby network (nearby home agent) may set up the potential to 
> compromise a MN's location privacy. "
> 
> 	s/"MN's location privacy"/"mobile node's location privacy"
> 
> - "The Mobile Node can either choose to request an 
> address, similar to DHCP, or the Mobile Node can request a prefix 
> on the home link then autoconfigure an address. "
> 
> 	s/"autoconfigure"/"auto-configure"
> 
> - "RFC 3775 [2] and 3776 [3] require that a Home Agent check 
> authorization on a home address received during a Binding Update."
> 
> 	s/"a Home Agent check authorization on a home address"/"a Home
> Agent checks authorization of a home address" ?
> 
> page 25:
> --------
> - "If the address is autoconfigured, RFC 3775 requires the Home Agent 
> to proxy-defend the address on the home link after the Mobile Node 
> performs the initial Binding Update. "
> 
> 	s/autoconfigure/auto-configure
> 

all fixed

> page 29:
> --------
> - some contributors are also in the ack section, some not. Is this
> intended?
> 

just for Jari that partecipates only at the beginning of the DT work but
then provided a deep review.

Thanks,
--Gerardo

> 
> Regards,
> 
> Kilian
> 
> 
> 
> _______________________________________________
> 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: "Kilian Weniger" <[email-masked]>
Date: Thu, 1 Dec 2005 13:51:30 +0100

Hi Gerardo,

please see comments inline

> the Binding Update, the DNS Update option, with the flag R not set.

IMHO it is clearer if "...in the option" is added to the sentence, i.e.,

"
For this purpose the Mobile Node MAY include a new mobility option in
the Binding Update, the DNS Update option, with the flag R not set in
the option.
"

> performed in the DNS server of the MSP.

yes

Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 1 Dec 2005 13:54:28 +0100

> > 
> > - " Please see other drafts that contain detailed 
> > mechanisms for localized home agent assignment, such as [15], "
> > 
> > 	There is no such section in [15] yet
> > 
> 
> section 3.2.2 of [15]. Isn'it the right section we are referring?

I should have quoted the whole sentence:

	 "Please see other drafts that contain detailed 
        mechanisms for localized home agent assignment, such as [15],
for 
        information on the location privacy properties of particular
home 
        agent assignment mechanisms. "

Section 3.2.2 in [15] describes local HA assignment, but IMHO the
reference refers to location privacy properties and they are not
addressed in [15] (at least not in the current version). 

Kilian

---

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 01 Dec 2005 14:15:05 +0100

Hi Kilian,

> the Binding Update, the DNS Update option, with the flag R not set in

OK, fixed.

--Gerardo

---

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 01 Dec 2005 14:12:09 +0100

> addressed in [15] (at least not in the current version). 

OK, you are right. However, this is an issue for the DHCP dratf. Kuntal,
please address it in the next version of the integrated draft.

--Gerardo

---

From: Gerardo Giaretta <[email-masked]>
Date: Tue, 06 Dec 2005 10:29:35 +0100

> >>>HoA as for all other addresses configured based on [ADDRCONF].
> >>
> >>we dont have to send everything thats there in a router
> >>advertisement through IKEv2 attributes. the mobile node
> >>can always run Mobile Prefix Discovery later on to find
> >>out the complete information about the home prefix.
> >>FWIW, Mobile Prefix Discovery was designed so that it
> >>can be a substitute for router advertisements when the
> >>mobile node is not at home.
> >>
> > 
> > 
> > But why the MN should run MPD to know the valid lifetime of 
> a prefix it
> > has already configured?
> > I was thinking that MPD would be used to discover new 
> prefixes, not the
> > prefix discovered via IKEv2.
> 
> because we dont to replicate everything that is there in
> the router advertisements through IKEv2 messages. :)
> 
> instead lets use MPD to get complete prefix information
> once you have setup security associations with the HA.
> this includes prefixes that you already know about. for
> example MPD even replicates the various flags (M, O flags).
>

OK, it seems that also Francis agrees with you. So let's keep only the
preferred lifetime.
I'll update the draft with the new format of the attribute. I'll also go
through the draft again to understand if we need to clarify in a better
way the usage of MPD.

--Gerardo 
 
> Vijay
> 
> > 
> > --Gerardo
> > 
> > 
> > 
> >>Vijay
> >>
> >>
> >>>--Gerardo
> >>>
> >>>
> >>>
> >>>>RFC 2461 says
> >>>>
> >>>> Preferred Lifetime
> >>>>                     32-bit unsigned integer.  The length 
> >>
> >>of time in
> >>
> >>>>                     seconds (relative to the time the 
> >>>>packet is sent)
> >>>>                     that addresses generated from the prefix via
> >>>>                     stateless address autoconfiguration remain
> >>>>                     preferred [ADDRCONF].  A value of 
> all one bits
> >>>>                     (0xffffffff) represents infinity.  See 
> >>>>[ADDRCONF].
> >>>>
> >>>>it might be sufficient to just send the preferred
> >>>>lifetime.
> >>>>
> >>>>Vijay
> >>>>
> >>>>
> >>>>
> >>>>>      0                   1                   2           
> >>
> >>        3
> >>
> >>>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
> >>>>
> >>>>6 7 8 9 0 1
> >>>>
> >>>>
> >>>>>     
> >>>>
> >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>
> >>>>
> >>>>>     |     Type      |    Length     | Prefix Length |L|A| 
> >>>>
> >>>>Reserved1 |
> >>>>
> >>>>
> >>>>>     
> >>>>
> >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>
> >>>>
> >>>>>     |                         Valid Lifetime              
> >>>>
> >>>>         |
> >>>>
> >>>>
> >>>>>     
> >>>>
> >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>
> >>>>
> >>>>>     |                       Preferred Lifetime            
> >>>>
> >>>>         |
> >>>>
> >>>>
> >>>>>     
> >>>>
> >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>
> >>>>
> >>>>>     |                           Reserved2                 
> >>>>
> >>>>         |
> >>>>
> >>>>
> >>>>>     
> >>>>
> >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>
> >>>>
> >>>>>     |                                                     
> >>>>
> >>>>         |
> >>>>
> >>>>
> >>>>>     +                                                     
> >>>>
> >>>>         +
> >>>>
> >>>>
> >>>>>     |                                                     
> >>>>
> >>>>         |
> >>>>
> >>>>
> >>>>>     +                            Prefix                   
> >>>>
> >>>>         +
> >>>>
> >>>>
> >>>>>     |                                                     
> >>>>
> >>>>         |
> >>>>
> >>>>
> >>>>>     +                                                     
> >>>>
> >>>>         +
> >>>>
> >>>>
> >>>>>     |                                                     
> >>>>
> >>>>         |
> >>>>
> >>>>
> >>>>>     
> >>>>
> >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>
> >>>>
> >>>>>--Gerardo
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>- Regarding DDNS updates, I share some of Francis concerns, 
> >>>>>>
> >>>>>>but I also
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>share the concerns of the DT stated in section 9.5.
> >>>>>>>(authentication/authorization of updates and 
> >>>>>>
> >>>>>>redirection-based flooding
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>issue, if MN updates DNS). IMHO some more 
> >>>>>>
> >>>>>>thoughts/discussions should be
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>spent on this issue. For instance, something like a 
> cookie-based
> >>>>>>>reachability test (done by DNS server) of the address 
> >>>>>>
> >>>>>>claimed by MN in
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>the DNS update could be considered to address the 
> >>
> >>redirection-based
> >>
> >>>>>>>flooding attack concern. 
> >>>>>>
> >>>>>>agree. but I think modifications to DNS are beyond
> >>>>>>the scope of MIP6 bootstrapping work.
> >>>>>>
> >>>>>>Vijay
> >>>>>>
> >>>>>>
> >>>>>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
> >>
> >>>>>===========================================================
> >>
> >>=========
> >>
> >>>>
> >>>>
> >>>
> >>>Gruppo Telecom Italia - Direzione e coordinamento di 
> >>
> >>Telecom Italia S.p.A.
> >>