Subject: [Gen-art] Gen-art review: draft-leung-cisco-mip4-host-config-03.txt

From: Elwyn Davies <[email-masked]>
Date: Tue, 13 Sep 2005 18:04:33 +0100

Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF.  We
advise the General Area Director (i.e. the IETF/IESG chair) by providing
more in depth reviews than he could do himself of documents that come up
for final decision in IESG telechat.  I was selected as the GenART
member to review this document.  Below is my review, which was written
specifically with an eye to the GenART process, but since I believe that
it will be useful to have these comments more widely distributed, others
outside the GenART group are being copied.

Document: draft-leung-cisco-mip4-host-config-03.txt
Intended Status: Informational (via RFC Editor)
Shepherding AD: Margaret Wasserman
Review Trigger: IESG Telechat 15/9/05

Summary:
This document needs some additional clarifications as regards association of 
extensions with registration requests and replies and some stronger security 
statements as regards data origin authentication.

I understand that this document is being put forward (with the mipv4 wg's 
blessing) to document existing implementations pending a wg sponsored 
standardisation based on draft-bharatia-mip4-gen-ext-00.txt and this work.

Review:
This document is intended to document a pre-standard vendor implementation of 
some work which will be shortly be standardized by the mipv4 wg.

The document is generally in good shape but needs a small number of clarifications:
- It should be made explicit which extensions are allowed in registration 
requests and which in registration replies.
- The sub-type fields in s3 should be explicitly stated to contain an integer 
from 0 to 255.
- The Home Network Prefix extension would be better named Home Network Prefix 
Length extension.
- In s3.1: It would be worth stating that other values of the selector are 
reserved... presumably some form of flag word was intended originally but this 
is now presumably moot.

Questions about the DHCP Client ID Extension:
- Regarding the summary in s2: If the Client ID is *really* used to obtain the 
IP address for the mobile node, this can only be done while the node is at home. 
  If the mobile node is booting up on a foreign network it needs to find its IP 
address by some other means than DHCP.  What is actually implemented here?  Is 
the home agent to query the DHCP server and obtain the client ID and pass it on? 
  Is the mobile node supposed to know what its Client ID is and pass it through 
the Home Agent which can use it on behalf of the mobile node?
- In s3.5, it should be made clear if this is expected to be in a registration 
request or a registration reply (or either).
- [Aside] There has been some discussion in the wg as to what information should 
be obtained through this sort of request.  Much of it could be obtained through 
DHCP once the mobile node is told the address of the DHCP server.  And there is 
no particular need for the home agent to know the DHCP Client ID as far as I can 
see.

Security: Russ Housely has already commented that stronger words are needed 
regarding data origin authentication.

Editorial:
s3.8: s/atmost/at most/
s5: s/information/informational/

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

---

From: [email-masked]
Date: Thu, 15 Sep 2005 14:47:27 -0700

Hi Elwyn.  Thanks for the review.  Comments below. 

> -----Original Message-----
> From: Elwyn Davies [mailto:[email-masked]] 
> Sent: Tuesday, September 13, 2005 10:05 AM
> To: [email-masked]
> Cc: Mary Barnes; margaret wasserman; Kent Leung (kleung); 
> Alpesh Patel (alpesh); [email-masked]; [email-masked]
> Subject: Gen-art review: draft-leung-cisco-mip4-host-config-03.txt
> 
> GenART is the Area Review Team for the General Area of the 
> IETF.  We advise the General Area Director (i.e. the 
> IETF/IESG chair) by providing more in depth reviews than he 
> could do himself of documents that come up for final decision 
> in IESG telechat.  I was selected as the GenART member to 
> review this document.  Below is my review, which was written 
> specifically with an eye to the GenART process, but since I 
> believe that it will be useful to have these comments more 
> widely distributed, others outside the GenART group are being copied.
> 
> Intended Status: Informational (via RFC Editor) Shepherding 
> AD: Margaret Wasserman Review Trigger: IESG Telechat 15/9/05
> 
> Summary:
> This document needs some additional clarifications as regards 
> association of extensions with registration requests and 
> replies and some stronger security statements as regards data 
> origin authentication.
> 
> blessing) to document existing implementations pending a wg 
> sponsored standardisation based on 
> draft-bharatia-mip4-gen-ext-00.txt and this work.
> 
> Review:
> This document is intended to document a pre-standard vendor 
> implementation of some work which will be shortly be 
> standardized by the mipv4 wg.
> 
> - It should be made explicit which extensions are allowed in 
> registration requests and which in registration replies.

Ok

> - The sub-type fields in s3 should be explicitly stated to 
> contain an integer from 0 to 255.

To clarify, this is what's requested in s3?

      Vendor-NVSE-Value:

         Format is shown below for each subtype, which is an integer
from 0 to 255.

> - The Home Network Prefix extension would be better named 
> Home Network Prefix Length extension.

Ok

> - In s3.1: It would be worth stating that other values of the 
> selector are reserved... presumably some form of flag word 
> was intended originally but this is now presumably moot.
> 

Ok

> - Regarding the summary in s2: If the Client ID is *really* 
> used to obtain the IP address for the mobile node, this can 
> only be done while the node is at home. 
>   If the mobile node is booting up on a foreign network it 
> needs to find its IP address by some other means than DHCP.  
> What is actually implemented here?  Is the home agent to 
> query the DHCP server and obtain the client ID and pass it on? 
>   Is the mobile node supposed to know what its Client ID is 
> and pass it through the Home Agent which can use it on behalf 
> of the mobile node?

I'll clarify:

HA performs proxy DHCP to obtain an IP address and other DHCP info from
the DHCP Server.  In the DHCP messages, the HA sets the Client ID to
uniquely identify the MN.  Typically the Client ID is associated with
the NAI of the MN.  The MN learns about the Client ID and DHCP Server in
the registration reply.  When MN returns to the home network, it can
extend the lifetime of the leased DHCP address by using this Client ID
in the DHCP Request message sent to the DHCP server.

> - In s3.5, it should be made clear if this is expected to be 
> in a registration request or a registration reply (or either).

Ok, specific item of first issue above.

> - [Aside] There has been some discussion in the wg as to what 
> information should be obtained through this sort of request.  
> Much of it could be obtained through DHCP once the mobile 
> node is told the address of the DHCP server.  And there is no 
> particular need for the home agent to know the DHCP Client ID 
> as far as I can see.
> 

Since the first registration has Home Address field set to 0.0.0.0 to
signify dynamic address assignment (RFC 2794), the HA needs to make sure
the value of the Client ID needs to be conveyed to the MN.  This allows
MN to renew its address when at home.  The HA needs to know about the
Client ID to renew the leased IP address when MN is roaming.  This
mechanism allows inactive MN to remain dormant (which saves battery) and
eliminates unnecessary airlink use. Only when MN is back at home, HA
deletes the mobility binding and terminates proxy DHCP functions. 

> Security: Russ Housely has already commented that stronger 
> words are needed regarding data origin authentication.
> 

I'm not clear on this.  Is "data origin authentication" about the
extension information being authenticated?  These extensions follow RFC
3344 method of authentication.  Not sure what's new that's less secure
than before?

> s5: s/information/informational/

Ok.

Thanks.  I'll resubmit after some clarifications.

Kent