Subject: [Mip4] Enterprise connectivity using MIP4 and MOBIKE

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Jul 2005 14:58:43 -0700

hi all,

the following draft describes using MIP4 and MOBIKE for enterprise
connectivity. this draft specifically avoids using dual-MIP (as
described in draft-ietf-mip4-vpn-problem-solution-01), when the VPN 
gateway supports MOBIKE extensions.

comments are welcome.

Vijay

-------- Original Message --------
Subject: I-D ACTION:draft-devarapalli-mip4-mobike-connectivity-00.txt
Date: Tue, 12 Jul 2005 15:50:02 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Secure Connectivity and Mobility using Mobile
                           IPv4 and MOBIKE
	Author(s)	: V. Devarapalli, P. Eronen
	Filename	: draft-devarapalli-mip4-mobike-connectivity-00.txt
	Pages		: 14
	Date		: 2005-7-12
	
    Enterprise users require mobility and secure connectivity when they
    roam and connect to the services offered in the enterprise.  Secure
    connectivity is required when the user connects to the enterprise
    from an untrusted network.  Mobility is beneficial when the user
    moves, either inside or outside the enterprise network, and acquires
    a new IP address.  This document describes a solution using Mobile
    IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure
    connectivity and mobility.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-devarapalli-mip4-mobike-connectivity-00.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

-- 
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: Ranjitsinh Wable <[email-masked]>
Date: Mon, 18 Jul 2005 10:49:23 +0530

Hi all,

Here I am having small question regarding the MIPv4.
Few days back on the mailing list I saw the discussion
about the HoA being 0.0.0.0 but what if the HA address
itself is zero. RFC 3344 does not talk about this case.
It talks about the dynamic HA discovery using the 
subnet broacast messages.

What if the HA address in the RRQ is 0.0.0.0.
Is it the same procedure to resolve the HA address
using NAI of the MN and AAA server? 

Is there any standard stating the use of NAI of MN
to resolve the HA of MN.

Thanks in advance.

Regards,

Wable R. U.

---

From: Pete McCann <[email-masked]>
Date: Mon, 18 Jul 2005 09:36:39 -0500

Hi, 

The use of ALL-ZERO-ONE-ADDR for the HA address is specified in
draft-ietf-mip4-dynamic-assignment-04.txt.  This may be a good
opportunity to remind the group that we should still be discussing the
resolution of Thomas Narten's comment on this draft, namely:

> >    Legacy Foreign Agent:
> >   
> >    Legacy foreign agents may forward a Registration Request with home
> >    agent field set to ALL-ZERO-ONE-ADDR by setting the destination IP
> >    address to ALL-ZERO-ONE-ADDR.  This will result packet being dropped
> >    or incidentally handled by a next hop HA, adjacent to the FA.   
> 
> hmm. how does one distinguish network connectivity problems from "not
> implemented"? I.e, what recovery action does a MN take in this
> situation?

We have had some discussion on this but I am not sure we reached a
final conclusion.

-Pete

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 21 Jul 2005 00:15:57 +0200

Hi Vijay,

> gateway supports MOBIKE extensions.

Some comments on the draft:

Overall:

  This is a pretty straightforward, easily accessible draft which
  provides a solution to an existing deployment problem.

  The draft would be improved by cleaning out unnecessary terminology
  inheritance from draft-ietf-mip4-vpn-problem-solution-01.  As an
  example, the term "i-HA" is used throughout the document, but as there
  is no external HA (x-HA) the document could just as well have used
  plain "HA", rather than "i-HA".  Generally all the "i-" prefixes
  seem unnecessary, and other terminology simplifications probably
  also can be done.

  There is also a bit too much repeated material.

  Symbolic references instead of numeric ones would also be nice.

Detailed comments:

[...]
>    Mobility extensions are IKEv2 are being standardized.  There is no
>    similar effort for IKEv1 [6].

s/are IKEv2 are/for IKEv2 are/

>    co-CoA: co-located Care-of address

CCoA is a more established abbreviation for Co-located Care-of Address

>        f: i-MIP with FA-CoA
>        c: i-MIP with co-CoA
>       mc: mobile enhanced VPN, i-MIP with VPN_TIA has co-CoA

I'm not sure these classifications are beneficial here, but if they're
to be used, then I suppose you mean "VPN_TIA as co-CoA" (or CCoA)

> 
>    The mobile node is configured with a home address that remains the
>    same irrespective of whether the mobile node is outside or inside the
>    enterprise network.  The mobile node is also reachable at the same
>    home address irrespective of its current point of attachment.  When
>    the mobile node is connected to the intranet directly, it uses Mobile
>    IP for internal mobility.  When it roams and connects to an untrusted
>    network outside the enterprise, it sets up a VPN tunnel to the VPN
>    gateway.  However, it still maintains a valid binding cache entry at
>    the i-HA.  It uses the VPN TIA, allocated by the VPN gateway, as the
>    co-located CoA for registration with the i-HA.  If the VPN TIA
>    changes or if the mobile node moves and connects to another VPN
>    gateway, then it sends a Registration Request to the i-HA using the
>    new co-located CoA.  If the mobile node moves while outside the
>    enterprise and its access network changes, it uses the MOBIKE
>    protocol to update the VPN gateway of its current address.  The
>    internal home agent is not aware of the mobile node's movement as
>    long as the mobile node is attached to the same VPN gateway and the
>    TIA remains the same.
> 
>    The following figure depicts the network topology assumed for the
>    solution.  It also shows the possible MN locations and access modes.
> 
> 
>        (MN) {mc}                             {home} (MN)   [i-HA]
>         !                                             \     /
>      .--+---.                                        .-+---+-.
>     (        )                                      (         )
>      `--+---'                      [MVPN]            `--+----'
>          \                           !                  !
>          [R/FA]                   .--+--.              [R]
>             \                    (  DMZ  )              !
>            .-+-------+--.         `--+--'         .-----+------.
>           (              )           !           (              )
>           ( external net +---[R]----[FW]----[R]--+ internal net )
>           (              )                       (              )
>            `--+---------'                         `---+---+----'
>              /                                       /     \
>    [DHCP]  [R]                              [DHCP] [R]     [R]    [i-FA]
>       \    /                                   \   /         \    /
>       .+--+---.                               .-+-+--.     .--+--+-.
>      (         )                             (        )   (         )
>       `---+---'                               `--+---'     `---+---'
>           !                                      !             !
>          (MN) {mc}                             (MN) {c}      (MN) {f}
> 
>    This results in a Mobile IP tunnel inside an IPsec tunnel.  The
>    Mobile IP tunnel is between the MN and the Home Agent and the IPsec
>    tunnel is between the MN and the mVPN gateway.  The Mobile IP tunnel
>    uses reverse tunneling through the Home Agent [12].

This paragraphs starts with "This results..." but I don't see what "This"
refers to.

> 3.1  Access modes
> 
>    The following access modes are used in the solution described in this
>    document.
> 
> 3.1.1  Access mode: 'c'
> 
>    This access mode is standard Mobile IPv4 [2] with a co-located
>    care-of address.  The mobile node MUST be able to detect that it is
>    connected to an internal trusted network before using this mode.  The
>    co-located care-of address is configured form the access network to
>    which the mobile node is attached to.

s/MUST be able to detect/must detect/
s/configured form/assigned by/

> 3.1.2  Access mode: 'f'
> 
>    This access mode is standard Mobile IPv4 [2] with a FA-located
>    care-of address.  The mobile node can use this mode only when it is
>    able to detect that it is connected to an internal trusted network
>    and detects a foreign agent on the access network.

s/is able to detect/detects/
s/and detects/and also detects/

> 3.1.3  Access mode: 'mc'
> 
>    This access mode involves using both Mobile IPv4 and MOBIKE enabled
>    IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec
>    tunnel.  The mobile node uses the IPsec TIA as the co-located CoA for
>    registering with the Home Agent.  This mode is used only when the
>    mobile node is attached to an untrusted network and is required to
>    setup an IPsec tunnel with a VPN gateway to gain access to the
>    trusted network.

s/and MOBIKE/and a MOBIKE/

> 3.2  Mobility within the enterprise
> 
>    When the mobile node is inside the enterprise network and attached to
>    the intranet, it uses Mobile IPv4 [2] for subnet mobility.  The
>    mobile node uses Foreign Agent co-located care-of address, if a
>    foreign agent is available.  Otherwise it acquires an address through
>    DHCP  on the access link and uses it as the care-of address (CoA) for
>    Mobile IP.  The mobile node attempts Foreign Agent discovery and CoA
>    address acquisition through DHCP simultaneously in order to avoid the
>    delay in discovering a foreign agent when there is no foreign agent
>    available.  The mobile node at any time maintains a valid binding
>    cache entry that maps the home address to the current CoA, at the
>    Home Agent.  Whenever the mobile node moves, it sends a Registration
>    Request to update the binding cache entry.

s/uses Foreign Agent co-/uses a Foreign Agent co-/

This is standard MIPv4, and I'm not sure this description is really
needed here; especially the detailed description of FA vs. co-located
operation.

>    The Mobile IP signaling messages between the mobile node and the Home
>    Agent are authenticated as described in [2].

The next paragraph doesn't belong under the section title above.  Either
move to the next section of add a section "Moving from within the
enterprise to the outside":

>    When the mobile node moves outside the enterprise and attaches to an
>    untrusted network, it sets up a VPN tunnel with the VPN gateway.  It
>    also maintains a valid binding cache entry at the Home Agent.  The
>    VPN TIA given out by the VPN gateway is used as care-of address for
>    Mobile IP registration.  If the mobile node attaches to another VPN
>    gateway or it re-connects to the same VPN gateway after a while, it
>    might get allocated a new TIA.  In such a case, the mobile node sends
>    a Registration Request to its Home Agent to update the binding cache
>    with its current TIA.
> 
> 3.3  Mobility when outside the enterprise
> 
>    When the mobile node is attached to an untrusted network, it sets up
>    a VPN tunnel with the VPN gateway to gain access to the enterprise
>    network.  IKEv2 [4] and IPsec [5] are used to setup the VPN tunnel.

Unnecessary repetition?

>    If the mobile node moves and its IP address changes, it initiates the
>    MOBIKE protocol [3] to update the address on the VPN gateway.  If the
>    TIA changes or the mobile node attaches to another VPN gateway, while
>    outside the enterprise, the mobile node should send a Registration
>    Request to its Home Agent using the new TIA as the co-located care-of
>    address.

Unnecessary repetition?

> 3.4  Crossing Security Boundaries
> 
>    Security boundary detection is based on the reachability of the i-HA
>    from the mobile node's current point of attachment.  Whenever the
>    mobile node detects that it has moved to a new IP subnet [13] and its
>    IP address changes, it sends a registration request to the i-HA
>    without any VPN encapsulation.  If the mobile node receives a
>    Registration Reply, then it is assumes that it is on a trusted
>    network.  This is based on the mechanism described in [10] to detect
>    attachment to the internal trusted network.  The mobile node should
>    re-transmit the Registration Request, if it does not receive the
>    Registration Reply within a timeout period.  The number of times the
>    mobile node should re-transmit the Registration Request and the
>    timeout period for receiving the Registration Reply are configurable
>    on the mobile node.

Superfluous comma: "...Request, if..."

>    If the mobile node has an existing VPN tunnel to its VPN gateway, it
>    MUST send a IKE MOBIKE message at the same time as the registration
>    request to the i-HA, whenever the IP address changes.  If the mobile
>    node receives a response from the VPN gateway, but not from the i-HA,
>    it assumes it is outside the enterprise network.  If it receives a
>    response from the i-HA, then it assumes it is inside the enterprise
>    network.

Superfluous comma: "...i-HA, whenever..."

>    There could also be some out-of-band mechanisms that involve
>    configuring the wireless access points with some information which
>    the mobile node can recognize as access points that belong to the
>    trusted network in an enterprise network.  Such mechanisms are beyond
>    the scope of this document.
> 
> 3.4.1  Operation when moving from an untrusted network
> 
>    When the mobile node is outside the enterprise network and attached
>    to an untrusted network, it has an IPsec VPN tunnel with its mobility
>    aware VPN gateway, and a valid registration with a Home Agent on the
>    intranet with the VPN TIA as the care-of address.
> 
>    If the mobile nodes moves and its IP address changes, it performs the
>    following steps:
> 
>    1.  Initiate IKE mobility exchange to update the current address with
>        the VPN gateway.  If the new network is also untrusted, this will
>        be enough for setting up the connectivity.  If the new network is
>        trusted, and if the VPN gateway is reachable, this exchange will
>        allow the mobile node to keep the VPN state alive while in the
>        trusted side.  If the VPN gateway is not reachable from inside,
>        then this exchange will fail.
>    2.  At the same time as step 1, send a Mobile IPv4 Registration
>        Request to the internal Home Agent without VPN encapsulation.
>    3.  If the mobile node receives a Registration Response to the
>        request sent in step 2, then the current subnet is a trusted
>        subnet, and the mobile node can communicate without VPN
>        tunneling.  The mobile node MAY tear down the VPN tunnel.

Arrghh!  With this material in 3.4.1, why do you need 3.3 ?  It seems
you have more cases than you need - are all of: internal, external,
internal->internal, external->internal, internal->external,
external->external really needed?  Even if you haven't described it
clearly divided in those 6 cases, it seems that in practice you are
going through all of them ...

> 3.4.2  Operation when moving from a trusted network
> 
>    When the mobile node is inside the enterprise and attached to the
>    intranet, it does not use a VPN tunnel for data traffic.  It has a
>    valid binding cache entry at its home agent.  If the VPN gateway is
>    reachable from the trusted network, the mobile node MAY have valid
>    IKEv2 security associations with its VPN gateway.  The IPsec security
>    associations can be created when required.  The mobile node may have
>    to re-negotiate the IKEv2 security associations to prevent them from
>    expiring.
> 
>    If the mobile node moves and its IP address changes, it performs the
>    following steps:
> 
>    1.  Initiate IKE mobility exchange to update the current address with
>        the VPN gateway, or if there is no VPN connection, then establish
>        a VPN tunnel with the gateway from the new local IP address.  If
>        the new network is trusted, and if the VPN gateway is reachable,
>        this exchange will allow the mobile node to keep the VPN state
>        alive, while in the trusted side.  If the new network is trusted
>        and if the VPN gateway is not reachable from inside, then this
>        exchange will fail.
>    2.  At the same time as step 1, send a Mobile IPv4 Registration
>        Request to the internal Home Agent without VPN encapsulation.
>    3.  If the mobile node receives a Registration Response to the
>        request sent in step 2, then the current subnet is a trusted
>        subnet, and the mobile node can communicate without VPN
>        tunneling, using only Mobile IP with the new care-of address.
>    4.  If the mobile node didn't receive the response in step 3, and if
>        the VPN tunnel is successfully established and registered in step
>        1, then the mobile node sends a Registration Request over the VPN
>        tunnel to the internal Home Agent.  After receiving a
>        Registration Response from the Home Agent, the mobile node can
>        start communicating over the VPN tunnel with the Mobile IP home
>        address.
> 
> 4.  NAT Traversal
> 
>    There could be a NAT device between the mobile node and the home
>    agent in any of the access modes, 'c', 'f' and 'mc', and between the
>    mobile node and the VPN gateway in the access mode 'mc'.  Mobile IPv4
>    NAT traversal, as described in [7] MUST be supported by the mobile
>    node and the home agent when the mobile node is using access modes
>    'c' or 'f'.  When using access mode, 'mc', IPsec NAT traversal [8]
>    [9] MUST be supported by the mobile node and the VPN gateway.
>    Typically, the TIA would be a routable address inside the enterprise
>    network.  But in some cases, the TIA could be from a private address
>    space associated with the VPN gateway.  In such a case, Mobile IPv4
>    NAT traversal should be used in addition to IPsec NAT traversal in
>    the 'mc' mode.

I don't see that it's a MUST to support MIPv4 NAT traversal within the
intranet.  It's a must (not a MUST) if you have internal NATs and want
MIPv4 to work, but that's not a protocol or implementation issue.  The
formulation in the last sentence of the paragraph is much more
appropriate.

> 5.  Security Considerations
> 
>    Enterprise connectivity, typically requires very strong security and
>    the solution described in this document was designed keeping this in
>    mind.

Superfluous comma: "...connectivity, typically..."

But the whole paragraph is perhaps superfluous, too...

>    Security concerns related to the mobile node detecting that is on a
>    trusted network and thereafter dropping the VPN tunnel are described
>    in [10].

It's not certain that 10 will be published.  Better cover it here.

>    Please see [3] for MOBIKE-related security considerations, and [7],
>    [8] for security concerns related to the use of NAT traversal
>    mechanisms for Mobile IPv4 and IPsec.

> 6.  IANA Considerations
> 
>    This document requires no action from IANA.
> 
> 7.  Acknowledgments
> 
>    The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval
>    Shah and John Cruz for their participation in developing this
>    solution.
> 
> 8.  References
> 
> 8.1  Normative References
> 
>    [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
>          Levels", BCP 14, RFC 2119, March 1997.
> 
>    [2]   Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
>          August 2002.
> 
>    [3]   Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
>          draft-ietf-mobike-protocol-00 (work in progress), June 2005.
> 
>    [4]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
>          draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
> 
>    [5]   Kent, S. and K. Seo, "Security Architecture for the Internet
>          Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress),
>          April 2005.
> 
>    [6]   Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
>          RFC 2409, November 1998.
> 
>    [7]   Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network
>          Address Translation (NAT) Devices", RFC 3519, May 2003.
> 
>    [8]   Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
>          "Negotiation of NAT-Traversal in the IKE", RFC 3947,
>          January 2005.
> 
>    [9]   Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
>          Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948,
>          January 2005.
> 
>    [10]  Vaarala, S., "Mobile IPv4 Traversal Across IPsec-based VPN
>          Gateways", draft-ietf-mip4-vpn-problem-solution-01 (work in
>          progress), January 2005.
> 
> 8.2  Informative References
> 
>    [11]  Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4
>          Traversal of VPN Gateways",
>          draft-ietf-mip4-vpn-problem-statement-03 (work in progress),
>          October 2004.
> 
>    [12]  Montenegro, G., "Reverse Tunneling for Mobile IP, revised",
>          RFC 3024, January 2001.
> 
>    [13]  Aboba, B., "Detecting Network Attachment (DNA) in IPv4",
>          draft-ietf-dhc-dna-ipv4-12 (work in progress), June 2005.
> 
> Appendix A.  Mobility Extensions for IKEv1

I have no comments on this appendix, apart from feeling that it might not
belong here ...

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 Jul 2005 16:17:05 -0700

hi Henrik,

thanks for the detailed review.

>   seem unnecessary, and other terminology simplifications probably

for the 00 version, we wanted to make sure we use the same
terminology that is used in draft-ietf-mip4-vpn-problem-solution.

>   Symbolic references instead of numeric ones would also be nice.

symbolic references tend to clutter up the text. so I prefer numberic
ones.

> needed here; especially the detailed description of FA vs. co-located

really? AFAIK, the simultaneous use of DHCP request and Foreign Agent
discovery is not defined anywhere. the mobile node first attempts agent
discovery and then does DHCP, right?

>>   Request to its Home Agent using the new TIA as the co-located care-of

I re-wrote sections 3.2 and 3.3. the updated text is at
http://people.nokia.net/vijayd/mipsec/mipsec.txt

> formulation in the last sentence of the paragraph is much more

you are right. fixed this.

    There could be a NAT device between the mobile node and the home
    agent in any of the access modes, 'c', 'f' and 'mc', and between the
    mobile node and the VPN gateway in the access mode 'mc'.  Mobile IPv4
    NAT traversal, as described in [7] should be used by the mobile node
    and the home agent in access modes 'c' or 'f', when there is a NAT
    device present.  When using access mode, 'mc', IPsec NAT traversal
    [8] [9] should be used by the mobile node and the VPN gateway, if
    there is a NAT device present.  Typically, the TIA would be a
    routable address inside the enterprise network.  But in some cases,
    the TIA could be from a private address space associated with the VPN
    gateway.  In such a case, Mobile IPv4 NAT traversal should be used in
    addition to IPsec NAT traversal in the 'mc' mode.

> It's not certain that 10 will be published.  Better cover it here.

oh.. I didnt know that. will do that.

> I have no comments on this appendix, apart from feeling that it might not

agreed. it will probably be moved to a separate document later on.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 Jul 2005 16:48:31 -0700

> oh.. I didnt know that. will do that.

[10] is draft-ietf-mip4-vpn-problem-solution-01. I guess you meant
the problem statement. (maybe I should use symbolic references...)

Vijay

---

From: Sami Vaarala <[email-masked]>
Date: Sat, 23 Jul 2005 04:38:05 +0300

Hi,

(Sorry for the long post.)

Nice work Vijay and Pasi.  MOBIKE and IKEv2 would be useful in
shaving off some overhead from an IKEv1-based solution.  However,
this reminded me of early discussion about MIPv4/VPN which is
more relevant in light of your draft.

The whole business of defining how MIPv4 and IPsec are used in a
particular context -- enterprise mobility -- suggests that an
applicability statement is probably the most suitable approach for
documenting how the protocols interact.

With minor exceptions, we're simply specifying how existing stuff
is used in a certain context to fulfill requirements specific to
the context.  The *only* significant exception in either draft
is the mechanism for detecting which access mode should be used.
This encompasses both how to detect the internal network and
whether FA or DHCP should be used, both MN issues.

What does this mean?  A few thoughts:

   1. New protocols are not needed, just a particular way to
      implement existing ones.  New protocols might be useful
      in making a solution more efficient, but that's another
      issue.

   2. IKEv1 will be around for some time, and not everyone will
      support MOBIKE, so it's likely that in the enterprise
      context people will be using IKEv1, IKEv2, and IKEv2 +
      MOBIKE.  Thus, access modes not involving MOBIKE may
      be useful.

   3. In addition to abovementioned VPN mechanisms, enterprises
      are also using L2TP/IPsec (PPP-over-L2TP-over-IPsec), so
      it's also a relevant as an access mode.  There are also
      other VPN variants in use.

To me, these imply that it may not be feasible, or useful, to
define a single solution (protocol) for the enterprise context:
there are simply too many VPN variations in use.  In fact, a
protocol implies some genuine interoperability requirements,
which are very few in both drafts: it's almost all about how
the network should be designed and how the MN should be
implemented.

There is IMO value in *illustrating* how the protocols work
together, e.g.:

    1. To make sure implementors don't miss out on issues which
       become relevant when the protocols are combined.

    2. To ensure that particular implementation methods are used
       when it matters.  E.g. detecting the internal network is
       security critical and should be implemented in a secure
       manner.  Security considerations in general are useful
       information for implementors.

    3. To minimize variation in implementations when there is
       a preferred implementation.

I guess the MIPv4 WG has been going back and forth about whether
a document should be published in this area.  Hopefully we'll
go one way or the other in the near future :-)

I believe that if we do decide to publish something, we should be
protocol agnostic at least for the VPN part and make sure the
document reads as an applicability statement and implementation
guidance, not as a definition of some specific new protocol.

Because I think some of the interactions between MIPv4 and VPN
mechanisms are not trivial, particularly w.r.t. security, an
informational RFC on the subject would be a useful thing.

Best regards,

-Sami

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 23 Jul 2005 05:13:12 +0200

> the problem statement. (maybe I should use symbolic references...)

No, the problem statement is in the RFC Editor's queue and will be
published.  I meant [10].

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 23 Jul 2005 05:30:47 +0200

[...]
> No, the problem statement is in the RFC Editor's queue and will be

Replying to my own posting here.

I should be a bit more expressive, I guess.  The reason I said the
above is that we've seen very little (i.e., zero) support and interest
in the working group after I asked for comments and review of [10]
some time ago.  But now I have an idea here:

If Vijay and Pasi will review [10] and see it's in good shape for
publication, I'm sure Sami will be willing to do the same for upcoming
versions of the MIP4/MOBIKE draft.  That way, we can make sure both will
be shipped :-)

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 23 Jul 2005 06:03:27 +0200

> terminology that is used in draft-ietf-mip4-vpn-problem-solution.

Ok.

> symbolic references tend to clutter up the text. so I prefer numberic

Well, we'll agree to disagree here, I think :-)

> discovery and then does DHCP, right?

I don't think either of these are defined anywhere - it's up to the
implementation.  The implementation I know most about does these and
other stuff as parallel as possible; and the other stuff is mostly
covered by draft-ietf-dhc-dna-ipv4.

> http://people.nokia.net/vijayd/mipsec/mipsec.txt

Yes, it looks better now.

>     addition to IPsec NAT traversal in the 'mc' mode.

Looks good.

> agreed. it will probably be moved to a separate document later on.

Ok, sounds good

	Henrik

---

From: Sami Vaarala <[email-masked]>
Date: Sat, 23 Jul 2005 14:58:38 +0300

Hi,

> versions of the MIP4/MOBIKE draft.  That way, we can make sure both will

Well, no problem there :)  But really, I believe these two drafts are
describing the same thing, only the VPN part is different.  I don't know
whether it will be useful to describe e.g. intranet detection and
related security issues twice, in separate drafts.

I'd rather merge the drafts or work on something more general, i.e.,
discussing intranet detection and security implications of using MIPv4
with *any* VPN protocol.

BR,

-Sami