Subject: Re: [Mip4] Working Group Last Call fordraft-ietf-mip4-mobike-connectivity-00

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 05 May 2006 16:01:32 -0700

hello,

Henrik, Kent, you are on the to list because
I have a question for you below.

[email-masked] wrote:
> Hi Vijay, 
> 
>> [email-masked] wrote:
>>> Hi,
>>>
>>> In general I support the advancement of this draft as a proposed
>>> standard. 
>> thanks.
>>
>>> I have, though, few minor comments & questions:
>>>
>>>  o The draft seems to be biased toward enterprise networks, at
>>>    least from the used terminology point of view. However, the
>>>    same solution would nicely fit e.g. into 'mobile operator'
>>>    controlled and hosted network deployments as well (thinking
>>>    e.g. 3GPP stuff here). Maybe few words about that would be 
>>>    good to have.. or slight change of wording (like enterprise
>>>    network -> trusted network etc)
>> its historical. MIPv4 has been working on
>> Enterprise connectivity solutions using MIPv4 and
>> VPNs for a while. so this was proposed an alternate
>> solution when IKEv2 with MOBIKE is used to setup
>> the VPN.
>>
>> we could in the appendix describe how this can be
>> applied to an operator's trusted/untrusted network.
>> however, this would need WG consensus.
> 
> Some lines around this would be nice.

I will write something up and send to the
mailing list soon.

> 
>>>  o Is there a reason why the case "FA integrated into MVPN"
>>>    has not been discussed? I have seen proposals like that.
>>>    Few lines about why and why not would be useful.
>> FA on the VPN gateway? I see enterprise VPN gateways
>> supporting IKEv2 and MOBIKE, but not foreign agents.
>> so thats why it isn't in the draft. I also wanted
>> to keep this spec simple.
>> however, there is another draft that talks about
>> this.
>> http://www.ietf.org/internet-drafts/draft-meghana-mip4-mobike-
>> optimizations-00.txt
> 
> Ok. I seem to have missed that draft. It might be worth at least
> giving an informative reference to this draft.

here is some text to be added to the end of
section 3.

  The overhead of running a Mobile IP tunnel inside an IPsec tunnel can
  be avoided by having the Mobile IP foreign agent functionality on the
  VPN gateway.  This is out of scope for this document and is further
  described in [14].

  >>>  o section 3.4 discusses about how the MN detects it has crossed
>>>    a security boundary. The current text only mentions that the
>>>    IP subnetwork has changed. It is possibly a bit far fetched
>>>    but in multi-radio MNs e.g. WLAN and GPRS interfaces can both
>>>    be given IPs from same private subnets belonging to different
>>>    operators (and thus different security 'domains'). 
>> I am afraid I didn't get this.
> 
> If you have e.g. a terminal with WLAN & GPRS and both radios enabled
> simultaneously. Then it is possible that both interfaces are configured
> with IPs from the same private subnetworks. So when the user roams
> he/she might attach to a GPRS network managed by mobile operator A
> (assigning IPs from 10.0.0.0/24) and to a WLAN network is operated by
> ISP B (also assigning IPs from 10.0.0.0/24). So I was just wondering
> whether this has any affect on the detection of crossing the security
> boundary as described currently in the draft.

this would be a problem with base MIPv4 itself,
right? the mobile node could have a WLAN and
GPRS interface and get the same private address
from these two networks. I don't think this is
handled in any of the current specifications.
I could be missing something. Henrik, Kent?

Vijay

-- 
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: Henrik Levkowetz <[email-masked]>
Date: Sat, 06 May 2006 12:20:11 +0200

Hi Vijay,

> I could be missing something. Henrik, Kent?

In practice, much more than just address checking is done.  The
best public description of an appropriate procedure is given in
RFC 4436.  MIPv4 vendors have had heuristics for this in their
products for years, though.

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 08 May 2006 10:53:40 -0700

> products for years, though.

there is already a reference to DNAv4 in this
draft. but there might be another issue. DNAv4
describes how to detect movement. but looks
like it assumes a single interface for a mobile
node. there could be a problem if the mobile
node has two interfaces attached two different
IP subnets but gets addresses from the same
private address space.

in the scenario described by Jouni, there is a
GPRS and a WLAN interface both up at the same
time. both interfaces get addresses from the
same private address space.

a smart mobile node implementation will be
able to handle this. we could just say it is
implementation specific. the other option is
to work on a specification which describes one
possible implementation option.

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 09 May 2006 05:10:32 +0200

Hi Vijay, Jouni,

> Henrik Levkowetz wrote:
...
> IP subnets but gets addresses from the same

I don't read DNAv4 that way at all.  I read it as applying to each
individual interface, and doing movement detection individually for
them.  

> same private address space.

Yes, but using DNAv4 your see a location as a tuple with at least
(IP-addr, Default-GW-mac-addr), so I don't see how that matters
at all.  The local address used at each interface is never seen
by the applications.  Of course, if you've left the routing tables
in place _below_ the tunnelling mechanisms, in the stack, they
may mess things up for you, but that would be a pretty silly thing
to do, I think?

Internally in a MIP client (and I imagine this is true for an
IPsec client too, maybe even more so) a tunnel would be bound to
an interface, not just to the local address, so as long as you do
the movement detection correctly, the local IP-address is just
an artifact of how the outer IP header has to look to be
acceptable once it leaves the interface - it shouldn't be seen
by either routing tables or applications, so whether it's a
public address, private address or even the exact same IP address
on two interfaces doesn't matter...

> possible implementation option.

As indicated above, I think it has to be one damn silly implementation
of IPsec and / or MIP to make this matter - it's not that a smart MN
will handle it right, its that you have to have a silly MN to handle
it wrong...  But maybe other people see this differently; in that case
some text to make this clear would be ok, I guess.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 May 2006 10:48:20 -0700

> on two interfaces doesn't matter...

you are right. agree completely.

> some text to make this clear would be ok, I guess.

if nobody else see this as something that needs
clarification, we don't need to add text anywhere.
anyway, draft-ietf-mip4-mobike-connectivity would
be the wrong place to talk about multiple
interfaces and private addresses.

Vijay