Subject: [Mip4] Summing up: draft-ietf-mip4-mobike-connectivity-01.txt

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 19 Dec 2006 11:08:23 -0500

Here is an attempted round-up of the issues that have been discussed:

1. Use of an FA

If the MN is on the trusted network, then an FA can be used.
There was a proposal from Vidya to put in the following text:

   "If the MN is moving from an untrusted network, it needs to first
acquire an IP address, try
    reaching the HA with it; if the HA is not reachable, use that
address as the VPN 
    tunnel outer address; if it is reachable, either operate in CCoA
mode or then use an FA 
    and re-register with the FA. OTOH, if the MN is moving from a
trusted network, it may 
    use an FA first; determine that the HA is unreachable, subsequently
acquire an IP 
    address and set up a VPN. "

However, there was a complaint that this might be over-specification.
Can the MN attempt to use an FA before it determines that it is on a
trusted network?  It seems to me that this is ok, the Registration Reply
will contain the MN-HA Authenticator if the FA can reach the HA,
otherwise
the MN will get no response or a response that fails the Authentication
check.
Personally I don't see the difference between the case of starting on an
untrusted
network vs. starting on the trusted network: the procedure could be the
same.

2. Bypass VPN for Registration Requests

There was discussion on whether it is feasible to bypass a VPN tunnel 
for the Registration Request.  I think the discussion concluded that
it was possible, but perhaps some text needs to be added describing
the SAD.  Does anyone have some concrete text to propose?

3. Security considerations for exposing the Registration Request

This one seems pretty simple, there is a short list of concerns that
could be written into the draft.  Vijay, can you draft some text?

Anything else outstanding that I missed?

-Pete

-- 
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: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 19 Dec 2006 10:32:38 -0800

I believe there are a couple of other things that Vijay already
suggested text for (Reverse tunneling; lack of mobility in VPN bypass
mode). One issue that I think is still open is support for multiple
interfaces (simultaneous bindings clarification). 

Vidya

> -----Original Message-----
> From: McCann Peter-A001034 [mailto:[email-masked]] 
> Sent: Tuesday, December 19, 2006 8:08 AM
> To: [email-masked]
> Subject: [Mip4] Summing up: draft-ietf-mip4-mobike-connectivity-01.txt
> 
>    "If the MN is moving from an untrusted network, it needs 
> to first acquire an IP address, try
>     reaching the HA with it; if the HA is not reachable, use 
> that address as the VPN 
>     tunnel outer address; if it is reachable, either operate 
> in CCoA mode or then use an FA 
>     and re-register with the FA. OTOH, if the MN is moving 
> from a trusted network, it may 
>     use an FA first; determine that the HA is unreachable, 
> subsequently acquire an IP 
> Can the MN attempt to use an FA before it determines that it 
> is on a trusted network?  It seems to me that this is ok, the 
> Registration Reply will contain the MN-HA Authenticator if 
> the FA can reach the HA, otherwise the MN will get no 
> response or a response that fails the Authentication check.
> Personally I don't see the difference between the case of 
> starting on an untrusted network vs. starting on the trusted 
> network: the procedure could be the same.
> 
> There was discussion on whether it is feasible to bypass a 
> VPN tunnel for the Registration Request.  I think the 
> discussion concluded that it was possible, but perhaps some 
> text needs to be added describing the SAD.  Does anyone have 
> some concrete text to propose?
> 
> This one seems pretty simple, there is a short list of 
> concerns that could be written into the draft.  Vijay, can 
> you draft some text?
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 19 Dec 2006 21:42:32 +0100

Hi Pete,

> Here is an attempted round-up of the issues that have been discussed:

...
> the SAD.  Does anyone have some concrete text to propose?

[Co-chair hat off]

Actually, I'd say this is a bit of over-specification, too.  Although
bypass rules should work fine, there are other ways of doing this than
to add bypass rules, too; for some implementations it would be much more
natural to simply use for instance a BPF tap or equivalent to do this.

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Dec 2006 16:20:20 -0800

> network vs. starting on the trusted network: the procedure could be the

Currently the draft already says

3.1.2.  Access mode: 'f'

    This access mode is standard Mobile IPv4 [2] with a foreign agent
    care-of address.  The mobile node can use this mode only when it
    detects that it is connected to an internal trusted network and also
    detects a foreign agent on the access network.

This addresses part of Hans' concerns about using
Internet FAs.

Now coming to the mobile node's behavior, there seems
to be consensus for the mobile node to always configure
a CoA, check reachability to the i-HA and and if
connected to a trusted network, may use a FA if one
available on the trusted access network. If we agree on
this, I can propose some text.

> the SAD.  Does anyone have some concrete text to propose?

I don't think any text is needed. You can bypass the
SPD using either a higher priority SPD entry with
source address set to the local IP address or using
some implementation specific mechanisms.

> could be written into the draft.  Vijay, can you draft some text?

Sent updated text this morning.

Narayanan, Vidya wrote:
> One issue that I think is still open is support for multiple

The mobile should be able to use simultaneous bindings.
I wasn't planning to prohibit it.

Vijay

---

From: Hans Sjostrand <[email-masked]>
Date: Wed, 20 Dec 2006 16:26:08 +0100

Pete and Vijay,

Some thoughts

1. Access mode home seams to be forgotten.
The answer there seams to be "Yes". Is the intention to pass WGLC 
without taking home mode in consideration?

3. Dual tunnel a normative reference
Vijay has proposed to make Dual tunnel a normative reference. I was sort 
of hoping that the draft-ietf-mip4-mobike-connectivity could be made 
self sufficient instead. But if it is the intention of the editors and 
working group to push these as a bundle I'm not the person to question 
that.

Regards
/// Hasse

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 Dec 2006 11:11:06 -0800

Hello,

> this, I can propose some text.

Here is some text to address this.

In section 3, add the following two paragraphs.

    Whenever the mobile node attaches to a new link, it may encounter a
    foreign agent.  The mobile node MUST not use the foreign agent
    care-of address with the i-HA when attached to an untrusted access
    network.  The default behavior for the mobile node is to always
    configure an address from the access link using DHCP.  The mobile
    node then checks if it is attached to a trusted access network by
    sending a registration request to the i-HA in the co-located care-of
    address mode.  If the mobile node discovers that it is attached to a
    trusted access network, then it MAY start using foreign agent care-of
    address with the i-HA.  In order to do this, the mobile node has to
    perform a new registration with the i-HA.

    The mobile node can use a foreign agent on a untrusted access
    network, if there is an external home agent that the mobile node is
    able to use.  The use of an external home agent in the untrusted
    access network and a home agent in the trusted access network at the
    same time is described in detail in [6].

In section 3.2, replace

    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 a foreign agent 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 co-located care-of address for Mobile
    IP.

with the following

    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 always configures a care-of address address through DHCP
    on the access link and uses it as the co-located care-of address.
    The mobile node MAY use a foreign agent care-of address, if a foreign
    agent is available.  However, the foreign agent care-of address is
    used only when the mobile node is attached to the trusted access
    network.

You can find the pre02 version of the draft at
http://dvijay.com/ietf/internet-drafts/mip4/mipsec.txt

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 Dec 2006 11:20:59 -0800

> without taking home mode in consideration?

The home address has not been considered as an access
mode in any of the MIP4 VPN documents so far. We can
either continue not counting this as an access mode,
or add a new access mode to the draft.

3.1.1.  Access mode: 'h'

    This access mode is standard Mobile IPv4 [2] when the mobile node is
    attached to its home link.  The mobile node must detect that it is
    connected to home link before using this mode.

It seems unnecessary to me. Comments anyone else?

> working group to push these as a bundle I'm not the person to question 

Yes, this is an issue. For now, I am hoping both
documents will advance as proposed standards. If ever
we need to make draft-ietf-mip4-mobike-connectivity
self contained, then we would have to add more text
on crossing security boundaries to the draft.

Vijay