Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

From: "John.zhao" <[email-masked]>
Date: Thu, 10 May 2007 09:40:28 +0800

Hi sangjin Jeong

         May I ask you a question, which should DHCP server send the DHCP
ForceRenew message to MN? The old one or new one or anyone?

         Best Rgds,

Thanks

John.zhao

---------------------------------------------------

Date: Wed, 9 May 2007 18:20:29 +0900

From: "Sangjin Jeong" <[email-masked]>

Subject: Re: [netlmm] I-D

         ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

To: "Ryuji Wakikawa" <[email-masked]>

Cc: [email-masked]

Message-ID: <028301c7921b$4b39a5f0$3570fe81@sjjeong>

Content-Type: text/plain;   charset="iso-8859-1"

Hi Ryuji,

Thanks for developing IPv4 support document.

There is a concern when MAG performs DHCP server functionality.

Actually, it was raised during initial version discussion, so I bring it
back.

According to the v4 support document, the following procedures will be
performed when LMA assigns IPv4 HoA.

 MN      MAG      LMA

  |------>|        |    1. DHCP discovery

  |       |------->|    2. Proxy Binding Update

  |       |<-------|    3. Proxy Binding Ack (IPv4HoA)

  |       |========|    4. Tunnel/Route Setup*

  |<------|        |    5. DHCP offer (IPv4 HoA)

  |------>|        |    6. DHCP request (IPv4 HoA)

  |<------|        |    7. DHCP acknowledgement

  |       |        |

* Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7)

  are processed in parallel.

In Step 5, DHCP offer will include server-id in the message and DHCP clients
will use the IP address provided in the server-id for any unicast requests
to the DHCP server.

Since LMA assigns MN's home network address and there is no DHCP server, MAG
should use its IP address as the server-id so that MAG can respond MN's DHCP
messages. 

MAG may use LMA address as the server-id. However, if MAG informs MN of LMA
address as a server address, MN will send DHCP messages to LMA address and
MAG will have to intercept them. 

IMHO, it is not a natural way for MAG to intercept/respond DHCP unicast
messages whose destination address is not itself.

Additionally, since MAG performs DHCP server-side function, specifying MAG's
address in DHCP message seems to be more reasonable.

IMHO, it is necessary to add following requirement in Step 5. 

"MAG uses its IP address as the server identifier in DHCP offer"

Also, if MAG's address is used as the server-id, there is another issue
related to MN's handover. 

Refer to the following figure, please. 

Let's assume a MN moved from old MAG (oMAG) to new MAG (nMAG)

MN     oMAG    nMAG      LMA

 |-------|------>|        |    1. MN attachment

 |       |       |------->|    2. Proxy Binding Update

 |       |       |<-------|    3. Proxy Binding Ack (IPv4HoA)

 |       |       |========|    4. Tunnel Setup

 .       .       .        .

 |------>|       |        |    5. DHCP request (renew)

 |       |       |        |

Since the MN does not know the link change, the DHCP client in the MN will
unicast DHCP request (renew) to the server IP address which was acquired by
oMAG (server-id). This might be undesirable behavior because oMAG maintains
state for the MN that is not in the access link anymore. Thus, DHCP client
in the MN needs to reconfigure its local configuration parameters. One
simple solution would be to force the DHCP client to renew its state by
sending DHCP FORCERENEW message as follows. 

MN     oMAG    nMAG      LMA

 |-------|------>|        |    1. MN attachment

 |       |       |------->|    2. Proxy Binding Update

 |       |       |<-------|    3. Proxy Binding Ack (IPv4HoA)

 |       |       |========|    4. Tunnel Setup

 |<------|-------|        |    5. DHCP FORCERENEW*

 |       |       |        |

* nMAG sends DHCP FORCERENEW to MN.

Regards,

Sangjin

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

---

From: "Sangjin Jeong" <[email-masked]>
Date: Thu, 10 May 2007 15:46:10 +0900

Hi John,

That will be the new MAG.

Regards,
Sangjin
  ----- Original Message ----- 
  From: John.zhao 
  To: [email-masked] ; [email-masked] 
  Cc: [email-masked] 
  Sent: Thursday, May 10, 2007 10:40 AM
  Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

  Hi sangjin Jeong

           May I ask you a question, which should DHCP server send the DHCP ForceRenew message to MN? The old one or new one or anyone?

           Best Rgds,

  Thanks

  John.zhao

  Cc: [email-masked]

  Hi Ryuji,

  Actually, it was raised during initial version discussion, so I bring it back.

  According to the v4 support document, the following procedures will be performed when LMA assigns IPv4 HoA.

   MN      MAG      LMA

    |       |        |

  In Step 5, DHCP offer will include server-id in the message and DHCP clients will use the IP address provided in the server-id for any unicast requests to the DHCP server.

  Since LMA assigns MN's home network address and there is no DHCP server, MAG should use its IP address as the server-id so that MAG can respond MN's DHCP messages. 

  MAG may use LMA address as the server-id. However, if MAG informs MN of LMA address as a server address, MN will send DHCP messages to LMA address and MAG will have to intercept them. 

  IMHO, it is not a natural way for MAG to intercept/respond DHCP unicast messages whose destination address is not itself.

  Additionally, since MAG performs DHCP server-side function, specifying MAG's address in DHCP message seems to be more reasonable.

   

  Also, if MAG's address is used as the server-id, there is another issue related to MN's handover. 

  MN     oMAG    nMAG      LMA

   .       .       .        .

   |       |       |        |

  Since the MN does not know the link change, the DHCP client in the MN will unicast DHCP request (renew) to the server IP address which was acquired by oMAG (server-id). This might be undesirable behavior because oMAG maintains state for the MN that is not in the access link anymore. Thus, DHCP client in the MN needs to reconfigure its local configuration parameters. One simple solution would be to force the DHCP client to renew its state by sending DHCP FORCERENEW message as follows. 

  MN     oMAG    nMAG      LMA

   |       |       |        |

  Regards,

  Sangjin

---

From: "John.zhao" <[email-masked]>
Date: Thu, 10 May 2007 16:30:36 +0800

Hi Sangjin

         Thanks at the first. But why does the client will believe the DHCP
ForceRenew message come from a new DHCP Server? Based on RFC 3203 , do you
think it allow this behavior?

         Best Rgds,

Thanks,

John.zhao

  _____  

发件人: Sangjin Jeong [mailto:[email-masked]] 
发送时间: 2007年5月10日 14:46
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi John,

Regards,

Sangjin

----- Original Message ----- 

From: John.zhao <mailto:[email-masked]>  

Cc: [email-masked] 

Hi sangjin Jeong

         Best Rgds,

Thanks

John.zhao

Cc: [email-masked]

Hi Ryuji,

 MN      MAG      LMA

  |       |        |

 

MN     oMAG    nMAG      LMA

 .       .       .        .

 |       |       |        |

MN     oMAG    nMAG      LMA

 |       |       |        |

Regards,

Sangjin

---

From: "Sangjin Jeong" <[email-masked]>
Date: Thu, 10 May 2007 20:04:55 +0900

Hi John,

I am not sure if I correctly understand your question.
I guess the DHCP server in your mail means MAG (or DHCP server
function in MAG).

The reason why the new MAG sends DHCP FORCERENEW message
is to update DHCP client's local configuration parameters, because these
parameters are for the old MAG.

Regards,
Sangjin

On 5/10/07, John.zhao <[email-masked]> wrote:
> ________________________________
>
>
> 主题: Re: [netlmm] I-D

-- 
---
---------------------------------------------
Sangjin Jeong
Researcher

Protocol Engineering Center
ETRI
161 Gajeong, Yusung, Daejeon, Korea, 305-700
Tel. +82-42-860-1877
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "John.zhao" <[email-masked]>
Date: Fri, 11 May 2007 10:07:31 +0800

Hi , Sangjin

	Thanks. The DHCP Server just is in the MAG in my context. But I only
doubt that the new MAG send a DHCP Forcerenew to MN to update some old
information. That ok. But if this behavior can be permitted between MN and
MAG? Because the new MAG isn't the provider of old parameters to MN. So if
it ask for change those parameters in MN to MN, that will leave the chance
for MN to be attacked. Seems anyone can send a DHCP ForceRenew to MN to ask
for this. That maybe a security problem. And in RFC3203, it seems didn't
mention that the sender of DHCP ForceRenew can be a new DHCP Server. So if
the old DHCP Server send the DHCP ForceRenew , that is ok. But if a new DHCP
Server send this message, why the dhcp client will follow the instruction of
it?

	Best Rgds,
Thanks.

John.zhao

-----邮件原件-----
发件人: Sangjin Jeong [mailto:[email-masked]] 
发送时间: 2007年5月10日 19:05
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi John,

Regards,
Sangjin

---

From: "Sangjin Jeong" <[email-masked]>
Date: Fri, 11 May 2007 13:05:00 +0900

Hi John,

As Ryuji already pointed out, if there exists a potential security 
vulnerability using ForceRenew message, letting MN go into rebind 
state could be another candidate. Thanks for your comment.

Regards,
Sangjin

----- Original Message ----- 
From: "John.zhao" <[email-masked]>
To: "'Sangjin Jeong'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, May 11, 2007 11:07 AM
Subject: RE: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi , Sangjin

Best Rgds,
Thanks.

John.zhao

-----邮件原件-----
发件人: Sangjin Jeong [mailto:[email-masked]] 
发送时间: 2007年5月10日 19:05
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi John,

Regards,
Sangjin

---

From: "John.zhao" <[email-masked]>
Date: Fri, 11 May 2007 12:13:25 +0800

Hi sangjin,

	Thanks. So necessary context transfer need to be considered to
ensure the rebind can work well.
	Best Rgds,
Thanks

John.zhao

-----邮件原件-----
发件人: Sangjin Jeong [mailto:[email-masked]] 
发送时间: 2007年5月11日 12:05
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi John,

Regards,
Sangjin

----- Original Message ----- 
From: "John.zhao" <[email-masked]>
To: "'Sangjin Jeong'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, May 11, 2007 11:07 AM
Subject: RE: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi , Sangjin

Best Rgds,
Thanks.

John.zhao

-----邮件原件-----
发件人: Sangjin Jeong [mailto:[email-masked]] 
发送时间: 2007年5月10日 19:05
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi John,

Regards,
Sangjin