Subject: RE: [Mip4] WGLC: draft-ietf-mip4-gen-ext-00.txt

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Thu, 1 Feb 2007 11:36:37 -0800

Hi Vijay.  Sorry for the delay.  Appreciate your thorough review. Since
most of your comments are accepted, I've only responded to the ones that
need further discussion.  My comments in "KL>" and Kuntal's in "[KC>]".

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Wednesday, October 25, 2006 7:07 PM
To: [email-masked]
Cc: McCann Peter-A001034; Henrik Levkowetz
Subject: Re: [Mip4] WGLC: draft-ietf-mip4-gen-ext-00.txt

this document needs some work before it can be sent to the IESG.

at a high level we need to say that this document defines a new
configuration options exchange extension, but we just use the extension
to carry the DHCP and BOOTP options as defined in RFC 2132.

the security considerations section needs some serious consideration. :)

some specific comments.

KL> This is same as last comment.  

>    This document describes the mechanism for providing the host
>    configuration information during Mobile IP registration.  

perhaps mention here that this is primarily for home link information.
for configuration information on the visited link, you are better off
using DHCP on the visited link.

KL> Agree that primarily the information is for home network parameters.
But foreign network parameters may also be embedded as described in the
draft.  The reason is that in some cases, there is no DHCP exchange
between MN and DHCP server in the foreign network.  For example, a MIPv4
registration by the MN via the FA using FA CoA doesn't require DHCP.
Some deployments use PPP/IPCP.  Maybe it's possible to follow RFC 1877
to obtain DNS Server addresses, but not flexible to obtain other
parameters.

[KC>] A few other reasons: the visited domain is not guaranteed to have
DHCP. The MN is not guaranteed to have DHCP Client either. These are
true statements for many of the wireless networks we use today.

Performance issue: If the config parameters are returned to the MN along
with RRP w/o requiring another round trip using DHCP, it speeds up
network entry.

>    One or more
>    Configuration Options Exchange Extensions may be included in the
>    registration message to provide the Mobile Node the configuration
>    parameters needed for network service usage (e.g.  DNS).

what is "network service usage"? network access?

KL> This means use of network services such as DNS.

<snip>

>          This field indicates which Mobility Agent was asked or
inserted
>          the extension in the Registration Request or Registration
>          Reply, respectively.  

suggest re-wording to

    This field indicates which mobility agent the request was
    sent to when the extension is present in a Registration
    Request and which mobility agent inserted the extension in
    a Registration Reply.

or something like that...

KL> maybe like this

    This field indicates which Mobility Agent is requested
    to provide configuration information when the extension is
    present in a Registration Request and which Mobility Agent 
    inserted the extension in a Registration Reply.

<snip>

>    list of requested parameters is specified as a string of octets,
>    where each octet is a valid DHCP option code as defined in
[RFC2132].
>    If this extension is included in the Registration Request, the Home
>    Agent or Foreign Agent (indicated in the Entity-Type field) should
>    provide requested information in the Registration Reply.  The
>    Configuration Options Exchange extension should be repeated in the
>    Registration Request for parameter(s) request based on the Entity-
>    Type.  If there are no Configuration Options Exchange Extension in
>    the Registration Request, it's up to the Home Agent or Foreign
Agent
>    to decide which configuration parameter to include in the
>    Configuration Options Exchange extension.  The configuration
>    parameter(s) should not be overwritten by the Foreign Agent if the
>    Home Agent has included them in the Configuration Options Exchange
>    extension.  The Entity-Type field is set to the Mobility Agent that
>    appended the extension in the Registration Reply.
> 
>    When a network entity (identified in the Entity-Type field of the
>    extension)

network entity includes the mobile node also in this case. wonder if
"network entity" is the right term.

KL> Will change to "Mobility Entity".

< adds a Configuration Options Exchange Extension to a
>    Registration Request or Registration Reply message, this extension
>    MUST appear prior to any authentication extensions added by that
>    entity.
> 
>    Example:
> 
>    Mobile Node wants to obtain the home network prefix mask and DNS
>    servers' IP addresses from its Home Agent during registration.  The
>    Registration Request would contain the following values in the
>    Configuration Options Exchange Extension.
> 
>    0               1                   2               3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     <Type>    |     <Len>=6   |    <Ent>=1    |    <Rsv>=0    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

what is "Rsv"?

KL> Should be "<DHCP>=1".

>    |  <OpCode>=55  |   <OpLen>=2   |  <NetMask>=1  |    <DNS>=6    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

what is "OpCode=55"?

KL> This is Parameter Request List as defined in RFC 2132.  Need to add
description in the text.

<snip>

> 5.  Security Considerations
> 
>    There are no additional security aspects imposed by this document
in
>    addition to the one defined in [RFC3344].

is that true? typically information that is being exchanged here is sent
one-hop from the access network to the mobile node. or at least it is
contained in the access network. now we are sending this information
across the Internet unencrypted.
for e.g. we are sending the IP address of the DNS server to a remote
mobile node without encrypting the information. so its not possible that
there are no new security considerations.

KL> Today, no extensions are encrypted in the registration messages
between foreign network and the home network.  This is typically not an
issue.  If it is considered to be a problem, then usually some site to
site security is set up using SLA between the MNOs.  I don't see a need
for encrypting the extensions.  BTW, I'm thinking of writing up a draft
that provides generic encryption of extensions (i.e. Encrypted Payload
Extension which is a wrapper of other extensions, e.g. Type, Length,
SPI, Payload=extensions).  But so far, there hasn't been a serious need.
If MIP extensions need to be encrypted, then it should be a generic
function and not specific to host configuration, IMHO.

Kent

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/