Subject: [netlmm] More comments on draft-ietf-netlmm-proxymip6-05.txt

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 21 Sep 2007 11:33:54 +0200

Hi Sri, 

I quickly went through the new draft. Good work, it has improved a lot.
However, I have some more comments:

- According to section 5.3, the LMA is allowed to accept a
de-registration PBU even if the PBU comes from an address different than
the current Proxy-CoA in the BCE. I think this should not be be allowed
- or only if the access link technology is able to detect the event that
the MN leaves the MAG very quickly. The reason is that if the access
link technology needs long time to detect the absence of the MN after a
handover, the de-registration may be sent by the old MAG after the PBU
from the new MAG is sent, which would delete the BCE and result in lack
of session continuity.

- Let's assume that the PBU from the new MAG after a handover is
received at the LMA more than MinDelayBeforeBCEDelete (default: 1s)
after the de-registration of the old MAG (e.g., due to long handover or
network auth time or PBU delay). In this case, the LMA would delete the
BCE for the MN before it receives the new PBU. I guess according the LMA
would handle this PBU as initial registration and, i.e., allocate a new
prefix to the MN, which means the session breaks. I think this scenario
is not unlikely to occur with the current default value of only 1s for
MinDelayBeforeBCEDelete. To be on the save side, I would propose a much
higher default value, e.g., 30s.

- The current text in section 5.3 may allow unauthorized nodes to find
out whether a MN has a BCE at a specific LMA as well as the link-local
address of the MN.

     "The Link-local Address option MUST be present in the Proxy Binding
      Acknowledgement message, if the same option was present in the
      corresponding Proxy Binding Update request message.  If there is
      an existing Binding Cache entry for that mobile node with the
      link-local address value of ALL_ZERO (value not set), or if there
      was no existing Binding Cache entry, then the link-local address
      MUST be copied from the received Link-local Address option in the
      received Proxy Binding Update request.  For all other cases, it
      MUST be copied from the Binding Cache entry.

It should be clarified that the LMA may only copy the link-local address
from the BCE in the PBA, if the PBU was valid (i.e., status code in PBA
< 128). 

- section 5.4 says 

     "Upon receipt of a Proxy Binding Update message with the Timestamp
      option, the local mobility anchor MUST check the timestamp field
      for validity.  In order for it to be considered valid, the
      timestamp value contained in the Timestamp option MUST be close
      enough to the local mobility anchor's time-of-day clock and the
      timestamp MUST be greater than all previously accepted timestamps
      in the Proxy Binding Update messages sent for that mobile node."
      
     "If the timestamp value in the received Proxy Binding Update is not
      valid, the local mobility anchor MUST reject the Proxy Binding
      Update and send a Proxy Binding Acknowledgement message with
      Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch).  "

According to this text, the TIMESTAMP_MISMATCH is sent everytime a PBU
overtakes another PBU, even if MAGs and LMA are in sync. Any reason for
this? I think the last paragraph should say 

      "if the timestamp value contained in the Timestamp option is not
close enough to the local mobility anchor's time-of-day clock, the local
mobility anchor MUST reject the Proxy Binding Update and send a Proxy
Binding Acknowledgement message with
      Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch)."

- There may be a problem if the host happens to activate more than one
network interface (e.g., two WLAN interfaces) and as a result is
attached to more than one MAG simultaneously. In this "error" case
multiple MAGs would send PBUs for the same host and the BCE at the LMA
would constantly change even though the host is not moving. Since the
draft assumes unmodified hosts, I guess we can't mandate that the MN
only activates one interface. However, it might be helpful for
implementors to add some text that the base draft assumes only one
active interface and that multiple interface support is future work.

- Section 6.9.2 begins with "The mobile node sends a Router Solicitation
message on the access link when ever the link-layer detects a media
change.". I think this is only the case if the MN implements DNA. If MN
doesn't implement DNA, it doesn't need to send RS when it changes links.

- section 5.3 seems to be a bit underspecified: What should LMA do if it
receives binding de-registration or re-registration with prefix 0::0?
What should LMA do with incoming data packets after valid
de-registration was received, but BCE still exists due to
MinDelayBeforeBCEDelete?

- The use of IPsec is not mandated according to section 4, but some
"MUST"s in the text still rely on Ipsec (see section 5.3, 6.9.1, 11).
E.g., "..It MUST use the SPI in the IPSec header [RFC-4306] of the
received packet for locating the security association needed for
authenticating the Proxy Binding Update request....The message MUST be
protected by using IPsec,"

- Section 6.14 talks about PMIP-MIP interactions scenario B and hence
should have an informative reference to
draft-giaretta-netlmm-mip-interactions-01.

BR,

Kilian

--------------------------------------------
Dr. Kilian Weniger
Panasonic R&D Center Germany
Monzastr. 4c, 63225 Langen, Germany
phone:  +49 (0)6103 766 137
fax:    +49 (0)6103 766 166
e-mail: [email-masked]
--------------------------------------------

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 24 Sep 2007 01:03:03 -0700

Hi Kilian,

Thanks for your review. Please see inline. 

> -----Original Message-----
> From: Kilian Weniger [mailto:[email-masked]] 
> Sent: Friday, September 21, 2007 2:34 AM
> To: Sri Gundavelli
> Cc: [email-masked]
> Subject: More comments on draft-ietf-netlmm-proxymip6-05.txt
> 
> Hi Sri, 
> 
> link technology needs long time to detect the absence of the 
> MN after af.org; Mon, 24 Sep 2007 04:03:25 -0400
From: "Sri Gundavelli" <[email-masked]>
To: "'Kilian Weniger'" <[email-masked]>
Date: Mon, 24 Sep 2007 01:03:03 -0700
Cc: [email-masked]
Subject: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt

Hi Kilian,

Thanks for your review. Please see inline. 

> -----Original Message-----
> From: Kilian Weniger [mailto:[email-masked]] 
> Sent: Friday, September 21, 2007 2:34 AM
> To: Sri Gundavelli
> Cc: [email-masked]
> Subject: More comments on draft-ietf-netlmm-proxymip6-05.txt
> 
> Hi Sri, 
> 

The LMA should not delete the BCE for that request. It should only
ACK the request. There is an explicit note now.

> higher default value, e.g., 30s.

Ok. I can increase the def value. Its a configurable parameter and
upto the deployment. Typically, the address manager component should
always attempt to give the same prefix to the same mobile node. The
prefix recycling should happen only when there are no prefixes to
allocate. This is generally a design goal of any address manager
components, used by DHCP or MIP. I will increase the def value slightly.

> from the BCE in the PBA, if the PBU was valid (i.e., status 

Ok.

>       Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch)."

I slightly modified the order of messages. But, there is a flow here
and the rules for timestamp validity determination are mentioned here.
If the LMA and MAG clocks are in sync, TIMESTAMP_MISMATCH is not sent.
Please let me know, if you are ok with this.

  o  Upon receipt of a Proxy Binding Update message 
> from the new MAG is sent, which would delete the BCE and 

The LMA should not delete the BCE for that request. It should only
ACK the request. There is an explicit note now.

> higher default value, e.g., 30s.

Ok. I can increase the def value. Its a configurable parameter and
upto the deployment. Typically, the address manager component should
always attempt to give the same prefix to the same mobile node. The
prefix recycling should happen only when there are no prefixes to
allocate. This is generally a design goal of any address manager
components, used by DHCP or MIP. I will increase the def value slightly.

> from the BCE in the PBA, if the PBU was valid (i.e., status 

Ok.

>       Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch)."

I slightly modified the order of messages. But, there is a flow here
and the rules for timestamp validity determination are mentioned here.
If the LMA and MAG clocks are in sync, TIMESTAMP_MISMATCH is not sent.
Please let me know, if you are ok with this.

  o  Upon receipt of a Proxy Binding Update message with the Timestamp
      option, the local mobility anchor MUST check the timestamp field
      for validity.  In order for it to be considered valid, the
      timestamp value contained in the Timestamp option MUST be close
      enough to the local mobility anchor's time-of-day clock and the
      timestamp MUST be greater than all previously accepted timestamps
      in the Proxy Binding Update messages sent for that mobile node.

   o  If the timestamp value in the received Proxy Binding Update is
      valid (validity as specified in the above considerations), the
      local mobility anchor MUST return the same timestamp value in the
      Timestamp option included in the Proxy Binding Acknowledgement
      message that it sends to the mobile access gateway.

   o  If the timestamp value in the received Proxy Binding Update is not
      valid (validity as specified in the above considerations), the
      local mobility anchor MUST reject the Proxy Binding Update and
      send a Proxy Binding Acknowledgement message with Status field set
      to TIMESTAMP_MISMATCH (Timestamp mismatch).  The message MUST also
      include the Timestamp option with the value set to the current
      time-of-day on the local mobility anchor.

> active interface and that multiple interface support is future work.

Ok.

> doesn't implement DNA, it doesn't need to send RS when it 

It should send RS any time it detects a media change. I will look
into this.

> de-registration was received, but BCE still exists due to

I thought this is covered. I will look into this.

> protected by using IPsec,"

This was discussed in the ML and as many pointed out, this is ok. I had
the same concern. The draft assumes IPsec as the default security
mechanism and the mandate of securing the messages is when IPsec is in
place. If IPsec is not used, this text is not relevant, the messages have
to protected using the semantics offered by the chosen security mechanism.
We cannot remove the "MUST" clause, the security directorate wont allow
this.

> draft-giaretta-netlmm-mip-interactions-01.

The draft does not talk any thing about CMIP/PMIP interactions. There
is no text related to this on the LMA. On the MAG, it only says, if
the MAG is not allowed for PMIP service, it can allow simple IPv6
address configuration to the MN, a normal access router property.

> fax:    +49 (0)6103 76with the Timestamp
      in the Proxy Binding Update messages sent for that mobile node.

   o  If the timestamp value in the received Proxy Binding Update is
      valid (validity as specified in the above considerations), the
      local mobility anchor MUST return the same timestamp value in the
      Timestamp option included in the Proxy Binding Acknowledgement
      message that it sends to the mobile access gateway.

   o  If the timestamp value in the received Proxy Binding Update is not
      valid (validity as specified in the above considerations), the
      local mobility anchor MUST reject the Proxy Binding Update and
      send a Proxy Binding Acknowledgement message with Status field set
      to TIMESTAMP_MISMATCH (Timestamp mismatch).  The message MUST also
      include the Timestamp option with the value set to the current
      time-of-day on the local mobility anchor.

> active interface and that multiple interface support is future work.

Ok.

> doesn't implement DNA, it doesn't need to send RS when it 

It should send RS any time it detects a media change. I will look
into this.

> de-registration was received, but BCE still exists due to

I thought this is covered. I will look into this.

> protected by using IPsec,"

This was discussed in the ML and as many pointed out, this is ok. I had
the same concern. The draft assumes IPsec as the default security
mechanism and the mandate of securing the messages is when IPsec is in
place. If IPsec is not used, this text is not relevant, the messages have
to protected using the semantics offered by the chosen security mechanism.
We cannot remove the "MUST" clause, the security directorate wont allow
this.

> draft-giaretta-netlmm-mip-interactions-01.

The draft does not talk any thing about CMIP/PMIP interactions. There
is no text related to this on the LMA. On the MAG, it only says, if
the MAG is not allowed for PMIP service, it can allow simple IPv6
address configuration to the MN, a normal access router property.

6 166

---

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 24 Sep 2007 11:11:40 +0200

Hi Sri,

please see inline. 

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Montag, 24. September 2007 10:03
> To: 'Kilian Weniger'
> Cc: [email-masked]
> Subject: RE: More comments on draft-ietf-netlmm-proxymip6-05.txt
> 
> Hi Kilian,
> 
> > MN after a

ok, I've seen the new note in draft-06:

	"If the received Proxy Binding Update request with the lifetime
      value of zero, has a Source Address in the IPv6 header, different
      from what is present in the Proxy-CoA address field in the Binding
      Cache entry existing for that mobile node, the local mobility
      anchor MAY either choose to ignore the request or send a valid
      Proxy Binding Acknowledgement message with the Status field set to
      0 (Proxy Binding Update Accepted).  However, it MUST NOT delete
      the mobile node's Binding Cache entry or modify the routing state
      created for that mobile node.

That's fine with me (although I would prefer an explicit "only accept
de-reg PBU if source address == Proxy-CoA address in BCE"...)

> allocate. This is generally a design goal of any address manager

Even if the address manager component gives the same prefix to the MN
when a new BCE is created, there would be no BCE and hence packet loss
until the next PBU arrives at the LMA.

The point is: what's the benefit of a small value for
MinDelayBeforeBCEDelete, except for marginally reducing the memory
consumption on the LMA? Is this worth the risk of significant packet
loss due to erroneously deleted BCE? 

> components, used by DHCP or MIP. I will increase the def 

My comment still applies in draft-06: The default value for
MinDelayBeforeBCEDelete is still 1s in draft-06. I think it should be
much higher.

Also, it would be good to have some text about too low values for
MinDelayBeforeBCEDelete to raise awareness to the implementor...

>       time-of-day on the local mobility anchor.

My comment still applies in draft-06, since the first paragraph still
says "In order for it to be considered valid,... the timestamp MUST be
greater than all previously accepted timestamps." So a
TIMESTAMP_MISMATCH may be returned even if the clocks are in sync.

Assuming MAG1 and MAG2 are in sync. MAG1 sends PBU1 at time t1 and MAG2
sends PBU2 at time t2 with t2>t1. If now PBU2 overtakes PBU1, i.e., PBU1
arrives at LMA after PBU2, the LMA would send a PBA with
TIMESTAMP_MISMATCH, even though MAG1 and MAG2 are in sync. 

I assumed so far that a TIMESTAMP_MISMATCH code shall tell the MAG that
its clock is out of sync for diagnostics purposes and potentially for
triggering the necessary actions to synchronize clocks again (e.g.,
using NTP). This is not really the case with the above text.

Maybe it is better to have two different status codes:
1. if the timestamp is not close enough to the local mobility anchor's
time-of-day clock
2. if the timestamp is lower than previously accepted timestamps
Only in the first case, the MAG should trigger necessary actions to
synchronize clocks...

> It should send RS any time it detects a media change. I will look

My comment still applies in draft-06. Sending RS is only a "may"
according to RFC2461 and RFC2461bis:

   "When an interface becomes enabled, a host may be unwilling to wait
   for the next unsolicited Router Advertisement to locate default
   routers or learn prefixes.  To obtain Router Advertisements quickly,
   a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router
   Solicitation messages each separated by at least
   RTR_SOLICITATION_INTERVAL seconds.  Router Solicitations may be sent
   after any of the following events:

      - The interface is initialized at system startup time.

      - The interface is reinitialized after a temporary interface
        failure or after being temporarily disabled by system
        management.

      - The system changes from being a router to being a host, by
        having its IP forwarding capability turned off by system
        management.

      - The host attaches to a link for the first time.

      - The host re-attaches to a link after being detached for some
        time."

> I thought this is covered. I will look into this.

I didn't see any related changes in draft-06. To be covered in draft-07?

> > "MUST"s in the text still rely on Ipsec (see section 5.3, 

ok

> address configuration to the MN, a normal access router property.

Well, it doesn't say "CMIP", but it says host-based mobility protocol ;)

If the host-based mobility protocol is MIPv6, then this is exactly
scenario B in draft-giaretta-netlmm-mip-interactions-01. So why not add
an informative reference? There is also a reference to the IPv4-PMIP
extension draft draft-ietf-netlmm-pmip6-ipv4-support-01.txt...

BR,

Kilian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Sep 2007 16:20:00 +0200

Kilian Weniger wrote:
[...]
>>> - Section 6.9.2 begins with "The mobile node sends a Router 
>>> Solicitation message on the access link when ever the link-layer
>>>  detects a media change.". I think this is only the case if the
>>> MN implements DNA. If MN doesn't implement DNA, it doesn't need
>>> to send RS when it changes links.
>>> 
> - The interface is reinitialized after a temporary interface failure
>  or after being temporarily disabled by system management.
> 
> - The system changes from being a router to being a host, by having 
> its IP forwarding capability turned off by system management.
> 
> - The host re-attaches to a link after being detached for some time."
> 
> 
On this particular topic.

For one, I think the mobile will do whatever it already does when
attaching to a new link: MLD REPORT first, RS first, NS first,
optimistic DAD, or DNA.  Our requirement is to not modify the mobile, so
we can't demand the mobile what to do first.

We thus can't assume that the mobile will do a RS first when it attaches.

The MAG should be able to react on any one of the following: linkup
trigger, NS, RS and even on MLD JOIN.

Nit:
> Further, if the mobile node uses an interface identifier that is not
>  based on EUI-64 identifier, such as specified in IPv6 Stateless 
> Autoconfiguration specification [RFC-2462], there is a very low 
> possibility of a link-local address collision between the two 
> neighbors on that access link.

I think you meant "id that _is_ based on EUI-64 identifier", right?  Or
you meant "for mobiles which negotiate addresses with a ptp lower layer
protocol the probability of collision is low?

And also maybe we should refer to draft-ietf-ipv6-rfc2462bis-08.txt
and/or rfc4862 instead of rfc2462?

I think for 802.16 access we can assume the address is formed from the
48bit MAC address.

Nit:
> 
> o  The mobile access gateway on receiving the Router Solicitation 
> message SHOULD send a Router Advertisement containing the mobile 
> node's home network prefix as the on-link prefix.  However, before 
> sending the Router Advertisement message containing the mobile node's
>  home network prefix, it SHOULD complete the binding registration 
> process with the mobile node's local mobility anchor.

I think it should say that the MAG should _have_ completed the binding
registration process; because the paragraph interpreted on itself means
the order of operations is like this: RS, PBU/PBAck, RA.  Or, figure 2
says it's: PBU/PBAck, RS, RA.  I think figure 2 is correct and the
paragraph above is incorrect, should contain the 'have completed'.

Nit:
> The mobile access gateway can learn the mobile node's link-local
> address, by snooping the DAD messages sent by the mobile node for

I think a better term than 'snooping' here is to require MAG to read the 
Target Address from the NS sent by the mobile with a src address field 
unspecified.  That's surely a DAD'ing NS.  Alternatively, the MAG could 
read the dst address of that NS and convert it from multicast to 
link-local unicast format.

An even faster way for MAG to learn that address is to read and 
interpret the MLD Report message sent by the mobile _before_ that NS was 
sent.

> establishing the link-local address uniqueness on the access link.
> Subsequently, at each handoff, the mobile access gateway can obtain
> this address from the local mobility anchor to ensure link-local
> address uniqueness and may change its own link-local address, if it
> detects a collision.

This I really don't understand.  A MAG will see only one attachment of a 
mobile, not any subsequent 'handovers'.  A handover involves two MAGs.

This is really unclear to me, sorry. 	

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 24 Sep 2007 12:01:55 -0500

Hi Kilian,

Please see one comment below.

Regards,

> > not
> >       send a Proxy Binding Acknowledgement message with 
> Status field 
> > set
> My comment still applies in draft-06, since the first 
> paragraph still says "In order for it to be considered 
> valid,... the timestamp MUST be greater than all previously 
> accepted timestamps." So a TIMESTAMP_MISMATCH may be returned 
> even if the clocks are in sync.
> 
> Assuming MAG1 and MAG2 are in sync. MAG1 sends PBU1 at time 
> t1 and MAG2 sends PBU2 at time t2 with t2>t1. If now PBU2 
> overtakes PBU1, i.e., PBU1 arrives at LMA after PBU2, the LMA 
> would send a PBA with TIMESTAMP_MISMATCH, even though MAG1 
> and MAG2 are in sync. 
> 
> I assumed so far that a TIMESTAMP_MISMATCH code shall tell 
> the MAG that its clock is out of sync for diagnostics 
> purposes and potentially for triggering the necessary actions 
> to synchronize clocks again (e.g., using NTP). This is not 
> really the case with the above text.
> 
> 1. if the timestamp is not close enough to the local mobility 
> anchor's time-of-day clock 2. if the timestamp is lower than 
> previously accepted timestamps Only in the first case, the 
> MAG should trigger necessary actions to synchronize clocks...

[Ahmad]

Just one clarification.
In the case that the P-BU coming from the same MAG or P-CoA, LMA SHALL
discard the P-BU. Otherwise, it is a race condition during a handoff
scenario and the LMA can send MN-Handoff-in-Progress or LMA SHOULD
ignore the P-BU. In case we are concerned about MAG1 retransmitting the
P-BU, LMA should send a revocation message to MAG1.

Thanks.
> > > detects a media change.". I think this is only the case if the MN 
> > > implements DNA. If MN doesn't implement DNA, it doesn't 
> need to send 
> > > RS when it changes links.
> > > 
> > 
> > It should send RS any time it detects a media change. I 
> will look into 
> > this.
>

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 24 Sep 2007 12:24:11 -0500

Hi Ahmad,

> P-BU, LMA should send a revocation message to MAG1.

Is this MN-Handoff-in-progress a new message that you are considering as a
solution to the problem? I don't think we should be considering adding more
signaling messages to the base protocol.

-Raj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 24 Sep 2007 12:31:10 -0500

Hi Raj,

Good catch. 

Since Kilian was proposing a new code I felt that probably understood.
My mistake.
I am proposing a new code "MN-Handoff-in-Progress" in the P-BA. 2 other
proposals are included too.

Any one should work.

Regards,
Ahmad

> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Monday, September 24, 2007 12:24 PM
> To: Muhanna, Ahmad (RICH1:2H10); Kilian Weniger; Sri Gundavelli
> Cc: [email-masked]
> Subject: Re: [netlmm] RE: More comments on 
> draft-ietf-netlmm-proxymip6-05.txt
> 
> 
> Hi Ahmad,
> 
> 
> > ignore the P-BU. In case we are concerned about MAG1 retransmitting 
> > the P-BU, LMA should send a revocation message to MAG1.
> 
> Is this MN-Handoff-in-progress a new message that you are 
> considering as a solution to the problem? I don't think we 
> should be considering adding more signaling messages to the 
> base protocol.
> 
> -Raj
> 
> > 
> > 
> > Thanks.
> 
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 24 Sep 2007 20:49:58 -0700

Hi Kilian,

Please see inline.

Thanks
Sri

> loss due to erroneously deleted BCE? 

Ok. I will change the default value.

> t1 and MAG2
> the MAG that

I see your point, I missed this case. We will discuss this offline and
I will update the text to cover this case.

>       - The host re-attaches to a link after being detached for some

Ok. I will update the text on this. 

> > > de-registration was received, but BCE still exists due to

Its not fixed in -06. I will cover this case and also on the
routing considerations during the MinDelayBeforeBCEDelete timer.

> extension draft draft-ietf-netlmm-pmip6-ipv4-support-01.txt...

:) My point is that its a simple IP case and nothing specific to
CMIP-PMIP interaction. I can add a reference to the doc, hopefully
the draft will be a WG doc before the LC is complete for this doc.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 24 Sep 2007 20:49:58 -0700

Hi Kilian,

Please see inline.

Thanks
Sri