Subject: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

From: Pete McCann <[email-masked]>
Date: Fri, 4 Nov 2005 11:41:01 -0600

We didn't get any followup to Gabriel's review here.  How does the
group feel about splitting 3012bis into two documents?

-Pete

gabriel montenegro writes:
 > I reviewed this document. I feel it is not quite RFC quality, being a bit confusing
 > and verbose/repetitive in sections. A big issue 
 > I have is that it is really two different things bunched together:
 > 	
 > - Challenge/Response extention
 > - Generalized Authentication Extension
 > 
 > They really should be two documents, specially cuz this is a revision, the proper 
 > opportunity to make such changes.
 > 
 > I'm also wondering about the use of MD5 throughout. Given recent developments, some
 > folks (not unanimously, though) are already calling for the deprecation of
 > SHA-1, and here we are recommending MD5 for a proposed standard? If this is what's
 > being used today, then this could be published as a historical or informational RFC, 
 > If the intent is to fix a few bugs in rfc 3012, perhaps the errata page is enough.
 > But the use of MD5 should be reviewed by the security ADs. CHAP should also be avoided,
 > due to its vulnerability to dictionary attacks.
 > For example, EAP advices against its usage (see rfc3748 section 7.6). Even more
 > explicitly, the EAP requirements for wireless usage call for mandatory
 > resistance to dictionary attacks: http://www.faqs.org/rfcs/rfc4017.html, section 2.2.
 > 
 > This comment applies to 3344bis as well.
 > 
 > Nit: saw "processing for" in several places. Shouldn't it be "processing of"?
 > 
 > Other comments interspersed below.
 > 
 > > 
 > > 
 > > 
 > > Network Working Group                                 Charles E. Perkins
 > > Internet-Draft                                     Nokia Research Center
 > > Expires: December 19, 2005                                Pat R. Calhoun
 > >                                                     Black Storm Networks
 > >                                                       Jayshree. Bharatia
 > >                                                          Nortel Networks
 > >                                                            June 17, 2005
 > 
 > Please update the author contact information now, instead of waiting for AUTH48.
 > 
 > ...
 > > Abstract
 > > 
 > ...
 > 
 > >    Furthermore, this document updates RFC3344 by including new
 > >    authentication extension called the Mobile-AAA Authentication
 > >    extension.  This new extension is provided so that a mobile node can
 > >    supply credentials for authorization using commonly available AAA
 > >    infrastructure elements.  This Authorization-enabling extension MAY
 > >    co-exist in the same Registration Request with Authentication
 > >    extensions defined for Mobile IP Registration by RFC3344.  This
 > >    document obsoletes RFC3012.
 > 
 > This should be a separate document.        
 > 
 > ...
 > 
 > > 1.  Introduction
 > > 
 > >    Mobile IP defines the Mobile-Foreign Authentication extension to
 > >    allow a mobile node to authenticate itself to a foreign agent.  Such
 > 
 > It can provide *mutual* authentication, right? Suggest making it explicit here
 > precisely because this extension differs in that it is unilateral. It does not aid the
 > MN in establishing legitimacy of the FA; only the opposite is true.
 > 
 > >    authentication mechanisms are mostly external to the principal
 > >    operation of Mobile IP, since the foreign agent can easily route
 > >    packets to and from a mobile node whether or not the mobile node is
 > >    reporting a legitimately owned home address to the foreign agent.
 > >    Unfortunately, that extension does not provide the foreign agent any
 > >    direct guarantee that the protocol is protected from replays, and
 > >    does not allow for the use of CHAP [RFC1994] for authenticating
 > 
 > See above comments on CHAP. Shouldn't be a motivation for a new PS document.
 > 
 > ...
 > > 2.  Mobile IP Agent Advertisement Challenge Extension
 > 
 > The organization of this section (describing a format), followed by the next section
 > on operation, followed by other sections (4 and 5) on packet formats is very
 > confusing. Suggest having all the packet formats bunched together, following each other. 
 > Also suggest preceding them by some section on overview of operation (perhaps section 3
 > itself.
 > 
 > ...
 > > 
 > >    The Challenge extension, illustrated in Figure 1, is inserted in the
 > >    Agent Advertisements by the foreign agent, in order to communicate a
 > >    previously unused challenge value that can be used by the mobile node
 > >    to compute an authentication for its next registration request
 > >    message.  The challenge is selected by the foreign agent to provide
 > >    local assurance that the mobile node is not replaying any earlier
 > >    registration request.  Eastlake, et al.  [RFC1750] provides more
 > >    information on generating pseudo-random numbers suitable for use as
 > >    values for the challenge.
 > 
 > Perhaps clarify that the transport of these is unicast.
 > 
 > > 2.1  Handling of Solicited Agent Advertisements
 > ...
 > >    advertised Challenges.  It must instead re-use the most recent of the
 > >    CHALLENGE_WINDOW Advertisement Challenge values.
 > 
 > This is the first time this is mentioned, and it is not explained. It is 
 > mentioned several times afterwards, but is never really explained until the
 > appendices. Explanation or at least a reference to the proper section
 > should accompany the first reference.
 > 
 > > 3.  Operation
 > > 
 > >    This section describes modifications to the Mobile IP registration
 > >    process [RFC3344] which may occur after the foreign agent issues a
 > >    Mobile IP Agent Advertisement containing the Challenge on its local
 > 
 > Given that Agent Advertisements can be multicast, I'd clarify here that
 > these are unicast.
 > 
 > ...
 >  
 > > 3.2  Foreign Agent Processing for Registration Requests
 > 
 > Perhaps s/for/of/  
 > E.g., 3344 uses "processing of" but never "processing for"
 > 
 > > 
 > >    Upon receipt of the Registration Request, if the foreign agent has
 > >    issued a Challenge as part of its Agent Advertisements, and it does
 > 
 > s/and it/and if it/
 > 
 > ...
 > 
 > >    unless the Registration Reply has already been
 > >    received from the home agent.  In this case the foreign agent MUST
 > >    preserve the value of the Code field set by the home agent and MUST
 > >    put its own rejection code only in the Status field of the FA Error
 > >    extension (defined in [FAERR]).
 > 
 > The above does not belong here, but in the next section (3.3) on handling
 > Registration Replies.
 > 
 > s/code only in/code in/
 > 
 > ...
 > >    with Code value FA_BAD_AAA_AUTH.  If the Mobile-AAA Authentication
 > >    Extension is present in the Registration Request, the foreign agent
 > >    MUST NOT remove the Mobile-AAA Authentication Extension and the
 > >    Mobile-Foreign Challenge Extension from the Registration Request.
 > 
 > s/Request./Request, before forwarding to the Home Agent./
 > 
 > >    Appendix C provides an example of an action that could be taken by a
 > >    foreign agent.
 > > 
 > >    In the event that the Challenge extension is authenticated through
 > >    the Mobile-Foreign Authentication extension and the Mobile-AAA
 > >    Authentication extension is not present, the foreign agent MAY remove
 > >    the Challenge Extension from the Registration Request without
 > >    disturbing the authentication value computed by the mobile node for
 > >    use by the AAA or the home agent.  
 > 
 > Sometimes "Challenge extension" and sometimes "Challenge Extension"
 > Please double-check throughout to make sure capitalization is consistent.
 > 
 > "use by the AAA" is confusing as it was just said that this case has no 
 > AAA, so perhaps clarifying text could be added:
 > 
 > s/home agent./home agent, the former because it is not present, the latter
 > because its calculation does not include the Challenge Extension.
 > 
 > Or one could reword, of course...
 > 
 > ...
 > 
 > >    If the foreign agent does not remove the Challenge extension, then
 > >    the foreign agent SHOULD store the Challenge value as part of the
 > 
 > notice the should here. But what if it's not stored? See below.
 > 
 > >    pending registration request list [RFC3344].  Also, if the
 > >    Registration Reply coming from the home agent does not include the
 > >    Challenge Extension, the foreign agent SHOULD NOT reject the
 > >    Registration Request message.  If the Challenge Extension is present
 > >    in the Registration Reply, it MUST be the same Challenge value that
 > >    was included in the Registration Request.  If the Challenge value
 > >    differs in the Registration Reply received from the home agent, the
 > >    foreign agent MUST insert an FA Error extension with Status value
 > >    HA_WRONG_CHALLENGE in the Registration Reply sent to the mobile node
 > >    (see Section 10).
 > 
 > The above section does not belong here but in the next section on Registration
 > Replies. Mixing section contents like this makes things very confusing.
 > 
 > Above, notice the MUST be the same Challenge value. But if the value was not
 > stored (as allowed by the SHOULD above), then what happens? The error recovery
 > and error status value above does not take that into account.
 >  
 > >    If the foreign agent does remove the Challenge extension and
 > >    applicable authentication from the Registration Request message, then
 > >    it SHOULD insert the Identification field from the Registration
 > 
 > s/insert/store/
 > 
 > >    Request message along with its record-keeping information about the
 > 
 > s/along with/as part of/
 > 
 > >    particular mobile node in order to protect against replays.
 > > 
 > > 3.3  Foreign Agent Processing for Registration Replies
 > 
 > s/for/of/
 > 
 > ...
 > >    If the foreign agent receives a Registration Reply with the Code
 > >    value HA_BAD_AAA_AUTH, it MUST be relayed to the mobile node.
 > 
 > Presumably, regardless of code value, the Reg Reply must be relayed,
 > yes? If so, why is this here? Suggest deleting the above as it is 
 > redundant. In general, there seems to be a lot of repetition. One
 > reads them carefully expecting there to be an exception to a rule,
 > but there is none, so it's just tiring.
 > 
 > > 3.4  Home Agent Processing for the Challenge Extensions
 > ...
 > 
 > >    The home agent MAY receive a Registration Request with the Mobile-AAA
 > 
 > s/MAY/may/
 > 
 > Does not seem prescriptive but merely describing an eventuality, so I don't
 > think we need rfc 2026 language here.
 > 
 > > 3.5  Mobile Node Processing for Registration Replies
 > ...
 > >    UNKNOWN_CHALLENGE: This error code is received by the mobile node in
 > >    the case where the mobile node has moved to a new foreign agent that
 > 
 > s/in the case where the mobile node/if it/
 > 
 > >    MISSING_CHALLENGE: A mobile node that does not include a Challenge
 > >    when the Mobile-Foreign Authentication extension is present may
 > >    receive a MISSING_CHALLENGE error.  In this case, the mobile node
 > >    SHOULD send a Challenge extension containing an unused challenge in
 > >    the next Registration Request.
 > > 
 > >    BAD_AUTHENTICATION: This error is sent by the foreign agent if the
 > >    Registration Request contains a Mobile-Foreign Authentication
 > >    extension with an incorrect authenticator that fails verification.  A
 > >    mobile node that receives a BAD_AUTHENTICATION Code value SHOULD
 > >    include the Mobile-AAA Authentication Extension in the next
 > >    Registration Request.  This will make it possible for the Foreign
 > >    Agent to use its AAA infrastructure in order to authenticate the
 > >    mobile node.  In this case, the mobile node MUST use a new Challenge
 > >    value in any new registration, obtained either from an Agent
 > >    Advertisement, or from a Challenge extension to the Registration
 > >    Reply containing the error.
 > > 
 > >    FA_BAD_AAA_AUTH: This error is sent by the foreign agent if the
 > >    Registration Request contains a Mobile-AAA Authentication extension
 > >    with an incorrect authenticator that fails verification.  A mobile
 > >    node that receives a FA_BAD_AAA_AUTH MUST use a new Challenge value
 > >    in any new registration, obtained either from an Agent Advertisement,
 > >    or from a Challenge extension to the Registration Reply containing
 > >    the error.
 > > 
 > >    HA_BAD_AAA_AUTH: This error is sent by the home agent if the
 > >    Registration Request contains a Mobile-AAA Authentication extension
 > >    with an incorrect authenticator that fails verification.  A mobile
 > 
 > s/incorrect//
 > 
 > >    node that receives a HA_BAD_AAA_AUTH MUST use a new Challenge value
 > >    in any new registration, obtained either from an Agent Advertisement,
 > >    or from a Challenge extension to the Registration Reply containing
 > >    the error.
 > > 
 > >    STALE_CHALLENGE: If the foreign agent receives a Registration Request
 > >    with a Challenge extension containing a Challenge value previously
 > >    used by that mobile node, the mobile node MAY receive a Registration
 > 
 > s/MAY/may/
 > 
 > >    Reply to the mobile node containing the Code value STALE_CHALLENGE.
 > >    In such instances, the mobile node MUST use a new Challenge value in
 > >    next Registration Request, obtained either from an Agent
 > >    Advertisement, or from a Challenge extension to the Registration
 > >    Reply containing the error.
 > > 
 > >    HA_WRONG_CHALLENGE: This error is sent by the foreign agent if the
 > >    Registration Reply from the home agent contains a different Challenge
 > >    value from the one included in the Registration Request.
 > 
 > s/the one/that/
 > 
 > Repetitiveness in the challenge rules was already taken care of by Jari's
 > comments, I believe. 
 >  
 > ...
 > 
 > > 4.  Mobile-Foreign Challenge Extension
 > > 
 > >    This section specifies a new Mobile IP Registration extension that is
 > >    used to satisfy a Challenge in an Agent Advertisement.  The Challenge
 > >    extension to the Registration Request message is used to indicate the
 > >    challenge that the mobile node is attempting to satisfy.
 > > 
 > >    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      |    Length     |          Challenge ...
 > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > > 
 > >              Figure 2: The Mobile-Foreign Challenge Extension
 > > 
 > >       Type:
 > > 
 > >          132 (skippable) (see [RFC3344])
 > > 
 > >       Length:
 > > 
 > >          Length of the Challenge value
 > > 
 > >       Challenge:
 > > 
 > >          The Challenge field is copied from the Challenge field found in
 > >          the Agent Advertisement Challenge extension (see section 2).
 > 
 > s/Agent Advertisement/received/
 > Cuz Agent Advertisements are not the only way to learn a Challenge.
 > 
 > > 5.  Generalized Mobile IP Authentication Extension
 > 
 > This really should be a separate document.
 > 
 > >    Several new authentication extensions have been designed for various
 > >    control messages proposed for extensions to Mobile IP.  A new
 > >    authentication extension is required for a mobile node to present its
 > >    credentials to any other entity other than the ones already defined;
 > >    the only entities defined in the base Mobile IP specification
 > >    [RFC3344] are the home agent and the foreign agent.  It is the
 > 
 > s/It is/The/
 > 
 > >    purpose of the generalized authentication extension defined here to
 > 
 > s/here to/here is to/
 > 
 > ...
 > > 6.  Mobile-AAA Authentication subtype
 > > 
 > >    The Generalized Authentication extension with subtype 1 will be
 > >    referred to as a Mobile-AAA Authentication extension.  The mobile
 > >    node MAY include a Mobile-AAA Authentication extension in any
 > >    Registration Request.  This extension MAY co-exist in the same
 > >    Registration Request with Authentication extensions defined for
 > >    Mobile IP Registration by [RFC3344].  If the mobile node does not
 > 
 > s/by//
 > 
 > >    include a Mobile-Foreign Authentication [RFC3344] extension, then it
 > 
 > s/[RFC3344]//
 > 
 > >    MUST include the Mobile-AAA Authentication extension whenever the
 > >    Challenge extension is present.  If both are present, the Mobile-AAA
 > >    Authentication extension MUST precede the Mobile-Foreign
 > >    Authentication extension.
 > > 
 > >    If the Mobile-AAA Authentication extension is present, then the
 > >    Registration Message sent by the mobile node MUST contain the Mobile-
 > >    Home Authentication extension [RFC3344] if it shares a security
 > 
 > notice this "if"
 > 
 > >    association with the home agent.  If both are present, the Mobile-
 > 
 > and this "if" as well.
 > This means that MN-HA Authentication is no longer a MUST, and that it
 > may be absent. I believe this is a departure from rfc 3344, and if so,
 > it should be flagged by explicitly saying so. 
 > 
 > ...
 > 
 > > 8.  SPIs for RADIUS AAA Servers
 > > 
 > >    Some AAA servers only admit a single security association, and thus
 > >    do not use the SPI numbers for Mobile IP authentication extensions
 > >    for use when determining the security association that would be
 > >    necessary for verifying the authentication information included with
 > >    the Authentication extension.
 > > 
 > >    SPI number CHAP_SPI (see Section 9) is reserved for indicating the
 > >    following procedure for computing authentication data (called the
 > >    "authenticator"), which is used by many RADIUS servers [RFC2138]
 > >    today.
 > > 
 > >    To compute the authenticator, apply MD5 [RFC1321] computed on the
 > >    following data, in the order shown:
 > > 
 > >       High-order byte from Challenge || Key ||
 > > 
 > >       MD5(Preceding Mobile IP data ||
 > > 
 > >       Type, Subtype (if present), Length, SPI) ||
 > > 
 > >       Least-order 237 bytes from Challenge
 > > 
 > >    where the Type, Length, SPI, and possibly Subtype, are the fields of
 > >    the authentication extension in use.  For instance, all four of these
 > >    fields would be in use when SPI == CHAP_SPI is used with the
 > >    Generalized Authentication extension.  Since the RADIUS protocol
 > >    cannot carry attributes of length greater than 253, the preceding
 > >    Mobile IP data, type, subtype (if present), length and SPI are hashed
 > >    using MD5.  Finally, the least significant 237 bytes of the challenge
 > >    are concatenated.  If the challenge has fewer than 238 bytes, this
 > >    algorithm includes the high-order byte in the computation twice, but
 > >    ensures that the challenge is used exactly as is.  Additional padding
 > >    is never used to increase the length of the challenge; the input data
 > >    is allowed to be shorter than 237 bytes long.
 > 
 > This draft starts by trying to help the FA, not the MN. so it should at least do
 > no harm to the MN. 
 > 
 > But this is something that can end up screwing the MN. Any device within RF
 > coverage of both can see everything above (including the challenge), except the
 > password used in CHAP. Given the weakness to dictionary attacks, an exchange like
 > the above effectively blasts the user's password to anybody who cares to listen.
 > This shouldn't be recommended. Or am I missing something?
 > 
 > ...
 > 
 > > 9.  Configurable Parameters
 > > 
 > >    Every Mobile IP agent supporting the extensions defined in this
 > >    document SHOULD be able to configure each parameter in the following
 > >    table.  Each table entry contains the name of the parameter, the
 > >    default value, and the section of the document in which the parameter
 > >    first appears.
 > > 
 > >        +------------------+---------------+---------------------+
 > >        | Parameter Name   | Default Value | Section of Document |
 > >        +------------------+---------------+---------------------+
 > >        | CHALLENGE_WINDOW | 2             | 3.2                 |
 > 
 > This has never been explained! And the first time it's mentioned is section 2.1.
 > 
 > >        |                  |               |                     |
 > >        | CHAP_SPI         | 2             | 8                   |
 > 
 > First time it's mentioned is section 3.1.
 > 
 > ...
 > 
 > > 10.  Error Values
 > > 
 > >    Each entry in the following table contains the name of the Code
 > >    [RFC3344] to be returned in a Registration Reply, the value for the
 > >    Code, and the section in which the error is first mentioned in this
 > >    specification.
 > 
 > Why is the first time it's mentioned that important? What should be
 > referenced is the section in which it is properly explained (which 
 > could be forward referenced from wherever it's mentioned for the 
 > first time).
 > 
 > > 
 > >        +--------------------+-------+--------------------------+
 > >        | Error Name         | Value | Section of Document      |
 > >        +--------------------+-------+--------------------------+
 > >        | UNKNOWN_CHALLENGE  | 104   | 3.2                      |
 > >        |                    |       |                          |
 > >        | BAD_AUTHENTICATION | 67    | 3.2 - also see [RFC3344] |
 > >        |                    |       |                          |
 > >        | MISSING_CHALLENGE  | 105   | 3.1, 3.2                 |
 > >        |                    |       |                          |
 > >        | STALE_CHALLENGE    | 106   | 3.2                      |
 > >        |                    |       |                          |
 > >        | FA_BAD_AAA_AUTH    | TBD   | 3.2                      |
 > >        |                    |       |                          |
 > >        | HA_BAD_AAA_AUTH    | TBD   | 3.4                      |
 > >        |                    |       |                          |
 > >        | HA_WRONG_CHALLENGE | TBD   | 3.2                      |
 > >        +--------------------+-------+--------------------------+
 > > 
 > >                            Table 2: Error Values
 > > 
 > 
 > Given the errors seen in the previous table, please double-check all the
 > above.
 > 
 > ...
 > 
 > > 12.  Security Considerations
 > > 
 > >    In the event that a malicious mobile node attempts to replay the
 > >    authenticator for an old Mobile-Foreign Challenge, the foreign agent
 > >    would detect it since the agent always checks whether it has recently
 > >    advertised the Challenge (see Section 3.2).  Allowing mobile nodes
 > >    with different IP addresses or NAIs to use the same Challenge value
 > >    does not represent a security vulnerability, because the
 > >    authentication data provided by the mobile node will be computed over
 > >    data that is different (at least by the bytes of the mobile nodes' IP
 > >    addresses).
 > 
 > OLD:
 >      at least by the bytes of the mobile nodes' IP addresses
 > 
 > NEW:
 >      at least the mobile node's IP address will vary
 > 
 > 
 > ...
 > 
 > 
 > >    Section 8 (SPI For RADIUS AAA Servers) defines a method of computing
 > >    the Generalized Mobile IP Authentication Extension's authenticator
 > >    field using MD5 in a manner that is consistent with RADIUS [RFC2138].
 > >    The use of MD5 in the method described in Section 8 is less secure
 > >    than HMAC-MD5 [RFC2104], and should be avoided whenever possible.
 > 
 > s/should/MUST/
 > But really, this MUST be avoided always, unless there's other (e.g., link-layer
 > mechanisms) that can help prevent the dictionary attacks. I guess the latter
 > applies throughout to the other methods as well.
 > 
 > >    Note that an active attacker may try to prevent successful
 > >    registrations by sending a large number of Agent Solicitations or
 > >    bogus Registration Requests, each of which could cause the foreign
 > >    agent to respond with a fresh challenge, invalidating the challenge
 > >    that the MN is currently trying to use.  To prevent such attacks, the
 > >    foreign agent MUST NOT invalidate previously unused challenges when
 > >    responding to unauthenticated Registration Requests or Agent
 > >    Solicitations.  In addition, the foreign agent MUST NOT allocate new
 > >    storage when responding to such messages, because this would also
 > >    create the possibility of denial of service.
 > 
 > Should say that it does not seek to provide any assurance to the MN, only
 > to the FA and infrastructure.
 > 
 > ...
 > > 14.  Normative References
 > > 
 > >    [FAERR]    Perkins, C., "Foreign Agent Error Extension for Mobile
 > >               IPv4", draft-perkins-mip4-faerr-00.txt (work in progress),
 > >               January 2004.
 > 
 > Update this reference to the latest version.
 > 
 > ...
 > > Authors' Addresses
 > ...
 > >    Pat R. Calhoun
 > >    Black Storm Networks
 > >    110 Nortech Parkway
 > >    San Jose, CA  95134
 > > 
 > >    Fax:   +1 720-293-7501
 > >    Email: [email-masked]
 > 
 > Update this info.
 > 
 > > Appendix A.  Change History
 > 
 > I like Jari's suggestion to detail the changes with respect to 3012.
 > 
 > ...
 > 
 > > Appendix B.  Verification Infrastructure
 > ...
 > >    In order to verify the credentials of the mobile node, we imagine
 > 
 > s/imagine/assume/
 > 
 > ...
 > 
 > > Appendix C.  Message Flow for FA Challenge Messaging with Mobile-AAA
 > >              Extension
 > ...
 > >    1.  The foreign agent disseminates a Challenge Value in an Agent
 > 
 > s/disseminates/includes/ 
 > s/an Agent/a unicast Agent/
 > 
 > ...
 > 
 > > Appendix E.  Foreign Agent Algorithm for Tracking Used Challenges
 > 
 > This section is normative, and is where we finally see the explanation
 > of how to use CHALLENGE_WINDOW. This should be in the body of the document
 > and must not remain in an appendix.
 > 
 > The appendix should only have the pseudo-code example.
 > 
 > -- 
 > 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/

-- 
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/

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 04 Nov 2005 09:52:07 -0800

Hello folks,

This document has been essentially ready to go for over a year.

How much longer will it take if we start from scratch with two
documents?

Maybe next year someone will demand that we merge them again.

Regards,
Charlie P.

---

From: Vijay Devarapallli <[email-masked]>
Date: Fri, 4 Nov 2005 16:21:13 -0800

> group feel about splitting 3012bis into two documents?

not at this late stage. its fine as it is. however, I have one comment
on the support for co-located CoA mode. the draft claims it supports
it but there really isnt enough detail. IMO, it should be clarified that
only FA mode is described in the draft.

Vijay