Subject: RE: [Mip6] Re: final edits to base drafts

From: [email-masked]
Date: Sat, 8 May 2004 23:13:49 -0700

hi Jari,

I went through the list. looks fine.

issue 332 needs some clarification. Home Address option MUST 
be present in the BU if the BU is sent from a visited link. 
If the BU is sent from the home link (a de-registration BU 
from home), the Home Address option MAY be omitted. in this 
case, the source address is used as the home address.

issue 327 has 4 issues.
1 - ?
2 - HA can skip checking the source address on the outer
    tunnel if packet is protected by IPsec. for all other
    tunneled packets, the HA MUST verify the source address
    on the outer tunnel against the CoA in the binding cache
    entry.
3 - it is not clear to me why the MN is reverse tunneling 
    the HoTi message from the home link. I was at 
    Connectathon, but dont remember the discussion. :(
4 - this just needs a clarification. if the MN is not  
    including a Home Address Option in a de-registration
    BU from the home link, it MUST set the lifetime to 0.
    if the lifetime is 0, it is always a de-registration BU.

Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Jari Arkko
> Sent: Saturday, May 08, 2004 4:38 PM
> To: Mobile IPv6 Mailing List
> Subject: [Mip6] Re: final edits to base drafts
> 
> 
> 
> Still some more issues, full list below:
> 
> - 333 Adopted  Soohong's nit on 8.2
> - 332 Open     Section 11.7.1 should not indicate HAO is optional
> - 331 Adopted? Hesham's on-link care-of address clarification
> - 330 Open     Frank Quick's IKE phase etc clarifications
> - 329 Adopted  Three/two rules in 10.3.1
> - 328 Adopted  Token/nonce terminology in 9.4.4
> - 327 Open     Connecthathon issues
> - 326 Adopted  Section 9.3.2 typo
> - 325 Adopted  BRR directly to the home address without RH?
> - 324 Adopted  Refresh interval is not absolute time
> - 323 Adopted  Not really silent discard if you send MPS
> - 322 Adopted  Typos reported by Jee
> - 321 Adopted  Typo reported by Jinmei
> - 320 Adopted  IANA and Status Codes
> 
> Most of these appear straightforward, though it would be
> good if you can check them out and give me an e-mail
> that you find them OK.
> 
> However, issues 327, 330, and 332 are unclear to me.
> At the very least we need suggested text for them and
> agreement on the list. Otherwise they'll be dropped
> from the current RFC and handled in a future update.
> 
> The detailed descriptions can be found from:
> 
> http://www.arkko.com/publications/mipv6/MIPv6-Issues.html
> 
> --Jari
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mip6
> 

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 09 May 2004 11:55:17 -0700

>     Connectathon, but dont remember the discussion. :(

I remember now. the MN sends a de-registration BU from the
home link, and wants to send a HoTi message from the home
link immediately. if the HA deletes the SPD entries when it
deletes the binding cache entry, a reverse tunneled HoTi
message could get dropped. it was suggested the Home Agent
keep the SPD entries alive for a short while before deleting
the SPD entries.

or the MN could wait for the binding ack to come back when
de-registering from the home link and then send a direct HoTi
message (not reverse tunneled) to the CN.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 May 2004 00:32:44 +0300

> case, the source address is used as the home address.

How about this. In Section 10.3.1, change

    o  A Home Address destination option MUST be present in the message.
=>
    o  A Home Address destination option MUST be present in the message
       (unless the home address appears as the source address).

In Section 11.7.1, change

    o  The packet MUST contain a Home Address destination option, giving
       the mobile node's home address for the binding.
=>
    o  The packet MUST contain a Home Address destination option (unless it
       is sent with the home address as the source address), giving
       the mobile node's home address for the binding.

This seems clear enough. But I worry a bit that we're forgetting
something; I can't remember why text was written the way it is.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 May 2004 00:33:14 +0300

> issue 327 has 4 issues.

I think part 1 shows that a clarification is needed
in the text. Here's the suggested edit:

Change

       Mobility Data = care-of address | correspondent | MH Data
       Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))

    Where | denotes concatenation and "correspondent" is the IPv6 address
    of the correspondent node.  Note that, if the message is sent to a
    destination which is itself mobile, the "correspondent" address may
    not be the address found in the Destination Address field of the IPv6
    header; instead the home address from the type 2 Routing header
    should be used.

to

       Mobility Data = care-of address | correspondent | MH Data
       Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))

    Where | denotes concatenation. "Care-of address" is the
    care-of address which will be registered for the mobile node
    if the Binding Update succeeds. Note that this address
    might be different from the source address of the Binding Update
    message, if the Alternative Care-of Address mobility option is
    used, or when the lifetime of the binding is set to zero.

    "Correspondent" is the IPv6 address
    of the correspondent node.  Note that, if the message is sent to a
    destination which is itself mobile, the "correspondent" address may
    not be the address found in the Destination Address field of the IPv6
    header; instead the home address from the type 2 Routing header
    should be used.

>     on the outer tunnel against the CoA in the binding cache

Right. Do you have suggested text? Do we need text?

>     message (not reverse tunneled) to the CN. 

I like the latter approach better. Is there a need to change
text?

>     if the lifetime is 0, it is always a de-registration BU.

Yes. Need for text change?

--Jari

---

From: Yukiyo Akisada <[email-masked]>
Date: Mon, 10 May 2004 14:04:31 +0900

Hi, Jari and Vijay.

I have some comments about issue 327.

On Mon, 10 May 2004 00:33:14 +0300

> Right. Do you have suggested text? Do we need text?

For me, I need the text.

At least I was confusing about this behavior
when developping the conformance test.

Especially, the last paragraph in section 10.4.5 should be more clear.
Vijay's sentence makes me clear.

> Yes. Need for text change?

I also need the text change about this.
It also confused me.

Regards.

----
Yukiyo Akisada <[email-masked]>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 May 2004 16:55:38 +0300

> Vijay's sentence makes me clear.

Ok.

I suggest adding the following text to the end of 10.4.5:

   This check is not necessary if the tunnel packet is
   accompanied by a valid ESP header.

> I also need the text change about this.

I have taken another look at the text. Section 11.5.4,
Returning Home, says this (my emphasis):

    A mobile node detects that it has returned to its home link through
    the movement detection algorithm in use (Section 11.5.1), when the
    mobile node detects that its home subnet prefix is again on-link.
    The mobile node SHOULD then send a Binding Update to its home agent,
    to instruct its home agent to no longer intercept or tunnel packets
    for it.  In this home registration, the mobile node MUST set the
    Acknowledge (A) and Home Registration (H) bits, set the *Lifetime
    field to zero*, and set the care-of address for the binding to the
    mobile node's own home address.  The mobile node MUST use its *home
    address as the source address* in the Binding Update.

Section 11.7.1 (sending bus) says this:

    o  The *packet MUST contain a Home Address destination option*, giving
       the mobile node's home address for the binding.

    o  The value specified in the Lifetime field SHOULD be less than or
       equal to the remaining valid lifetime of the home address and the
       care-of address specified for the binding.

Section 10.3.1 (reg), says this:

    o  A *Home Address destination option MUST be present* in the message.

Section 10.3.2 (de-reg), says this:

    A Binding Update is validated and authorized in the manner described
    in the previous section.

Section 9.5.1 (recv bu), says this:

    o  If the Lifetime specified in the Binding Update is nonzero *and* the
       specified care-of address is not equal to the home address for the
       binding, then this is a request to cache a binding for the home
       address.  If the Home Registration (H) bit is set in the Binding
       Update, the Binding Update is processed according to the procedure
       specified in Section 10.3.1; otherwise, it is processed according
       to the procedure specified in Section 9.5.2.

    o  If the Lifetime specified in the Binding Update is zero *or* the
       specified care-of address matches the home address for the
       binding, then this is a request to delete the cached binding for
       the home address.  In this case, the Binding Update MUST include a
       valid home nonce index, and the care-of nonce index MUST be
       ignored by the correspondent node.  The generation of the binding
       management key depends then exclusively on the home keygen token
       (Section 5.2.5).  If the Home Registration (H) bit is set in the
       Binding Update, the Binding Update is processed according to the
       procedure specified in Section 10.3.2; otherwise, it is processed
       according to the procedure specified in Section 9.5.3.

I think all the above is actually pretty clear. You need to know
if you are doing a reg or a de-reg. Then we have the following cases:

REG    - SENDER: HAO is mandatory, coa!=hoa, and lifetime!=0
          RECEIVER: HAO is mandatory, coa!=hoa, and lifetime!=0

DE-REG - SENDER: HAO is optional, coa=hoa, and lifetime=0
          RECEIVER: HAO is optional, coa=hoa or lifetime=0

The only things that you can't find from the text are:

- For a registration, the lifetime must be non-zero
   (and not just smaller than the address lifetime).

- For a de-registration, Section 10.3.2 refers to 10.3.1
   for the validation rules, which include "MUST have HAO".
   This relates to issue 332 as well (another e-mail).

I suggest that the two items be fixed as follows:

    o  The value specified in the Lifetime field SHOULD be less than or
       equal to the remaining valid lifetime of the home address and the
       care-of address specified for the binding.

=>

    o  The value specified in the Lifetime field SHOULD be non-zero and
       less than or
       equal to the remaining valid lifetime of the home address and the
       care-of address specified for the binding.

and

    A Binding Update is validated and authorized in the manner described
    in the previous section.

=>

    A Binding Update is validated and authorized in the manner described
    in the previous section, except that the use of the Home Address
    destination option is not required.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 May 2004 16:57:19 +0300

> something; I can't remember why text was written the way it is.

Indeed. After thinking about this again the change would
break things. Right now, we have separated registrations and
de-registrations to different sections, and that's why 10.3.1
and 11.7.1 require the HAO. Section 10.3.2 should not require
it however. See also what I proposed for the Connecthathon
issues.

So I take my #332 text proposal back and instead suggest
that we replace in Section 11.7.1 the following:

    The mobile node MUST use its
    home address - either in the Home Address destination option or in
    the Source Address field of the IPv6 header - in Binding Updates sent
    to the home agent.

with

    The mobile node MUST use its home address in Binding Updates sent
    to the home agent.

--Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 10 May 2004 10:08:16 -0700

Jari -

I've read through the issue text, and I don't think we want to make any

>     The mobile node MUST use its home address in Binding Updates sent

The current text that you propose changing is in a part of section 11.7.1
that is discussing interaction with Ipsec, it is followed by:

"  This is necessary in order to allow the Ipsec policies to be matched with
the right home address."

The current text is more general than just the topic of registering a new
primary care-of address, and I think that's OK because the section header is
also more general: "11.7.1 Sending Binding Updates to the Home Agent".

Thanks.
- Ed Remmell

Treck, Inc. (formerly Elmic Systems, USA)

Best of Show Winner, ESC 2003

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Monday, May 10, 2004 6:57 AM
> Cc: [email-masked]; [email-masked]
> Subject: Re: Issue 332 (Was: Re: [Mip6] Re: final edits to 
> base drafts)
> 
> Jari Arkko wrote:
> 
> it however. See also what I proposed for the Connecthathon issues.
> 
> So I take my #332 text proposal back and instead suggest that 
> we replace in Section 11.7.1 the following:
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.676 / Virus Database: 438 - Release Date: 5/3/2004
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.676 / Virus Database: 438 - Release Date: 5/3/2004

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 10 May 2004 11:15:34 -0700

>   accompanied by a valid ESP header.

we probably should make it more explicit by saying

    This check is not necessary if the reverse-tunneled packet
    is protected by ESP in tunnel mode.

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 10 May 2004 11:17:55 -0700

Some comments below about proposed issue #327 changes:

> I like the latter approach better. Is there a need to change text?

This is tricky when the MN is deregistering when on a foreign link. In this
case, there is no clear guidance in the draft about how to support
simultaneous MN deregistration of CN RO bindings and MN deregistration with
the home agent.

The former approach (HA keeps SPD entries alive for some short time after MN
deregistration) described above would support this, without requiring
changes on the MN.

In our MN, when we deregister on a foreign link we do something tricky to
handle this scenario: when we still have CN RO bindings to deregister, our
deregistration binding update to the home agent is actually a registration
binding update with a very short lifetime (so it will expire soon, but it
gives us enough time to complete our deregistration with the home agent).
This allows us to continue to use the tunnel through the home agent to
tunnel the HoTI and CoTI messages to CNs that we deregister RO bindings
with.

Thanks.
- Ed

---

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 10 May 2004 11:45:40 -0700

> In our MN, when we deregister on a foreign link we do 
> something tricky to handle this scenario: when we still have 
> CN RO bindings to deregister, our deregistration binding 
> update to the home agent is actually a registration binding 
> update with a very short lifetime (so it will expire soon, 
> but it gives us enough time to complete our deregistration 
> with the home agent).

Meant to type:
(so it will expire soon, but it gives us enough time to complete our
deregistration of CN RO bindings).

- Ed

---

---

From: Yukiyo Akisada <[email-masked]>
Date: Wed, 12 May 2004 11:08:03 +0900

Hi, Jari and Vijay.

On Mon, 10 May 2004 16:55:38 +0300

> >>>    if the lifetime is 0, it is always a de-registration BU.

(snip)

>           RECEIVER: HAO is optional, coa=hoa or lifetime=0

In the result,
BU (lifetime!=0) w/o HaO means DE-REG for receiver, right?

In my memory, 
at the last Connectathon,
Vijay said that the receiver also requires 'coa=hoa and lifetime=0' for de-registraion.
# In this case, the receiver was HA.

If the receiver disallows to receive BU (lifetime!=0) w/o HaO for de-registraion,
we need text change.

Which is the correct way?
I'm still confusing.

Thanks.

----