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

["Sangjin Jeong" <[e-mail]>]

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" <[e-mail]>
To: "'Sangjin Jeong'" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Friday, May 11, 2007 11:07 AM
Subject: RE: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt


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:[e-mail]] 
发送时间: 2007年5月10日 19:05
收件人: [e-mail]
抄送: [e-mail]; [e-mail]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

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 <[e-mail]> wrote:
>
>
>
> 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:[e-mail]]
> 发送时间: 2007年5月10日 14:46
> 收件人: [e-mail]; [e-mail]
> 抄送: [e-mail]
> 主题: Re: [netlmm] I-D
> ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt
>
>
>
>
>
> Hi John,
>
>
>
>
>
> That will be the new MAG.
>
>
>
>
>
> Regards,
>
>
> Sangjin
>
>
> ----- Original Message -----
>
>
> From: John.zhao
>
>
> To: [e-mail] ; [e-mail]
>
>
> Cc: [e-mail]
>
>
> 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
>
> ---------------------------------------------------
>
> Date: Wed, 9 May 2007 18:20:29 +0900
>
> From: "Sangjin Jeong" <[e-mail]>
>
> Subject: Re: [netlmm] I-D
>
>          ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt
>
> To: "Ryuji Wakikawa" <[e-mail]>
>
> Cc: [e-mail]
>
> 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
>
>


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

Protocol Engineering Center
ETRI
161 Gajeong, Yusung, Daejeon, Korea, 305-700
Tel. [phone]

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