Subject: RE: [Mip4] WGLC: draft-ietf-mip4-mobike-connectivity-01.txt

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 11 Dec 2006 10:23:03 -0500

Reminder: this WGLC ends tomorrow at midnight.  So far we
have gotten minimal feedback.  More support will be required
to advance this to the IESG.

-Pete

McCann Peter-A001034 wrote:
> This message announces a (second) WG last call on:
> 
>    "Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE"
>    draft-ietf-mip4-mobike-connectivity-01.txt
> 
> The last call will conclude at 24:00 UTC on Tuesday, 12 December 2006.
> 
> "Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE"
> 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-ietf-mip4-mobike-connectivity-
> 01.txt
> 
> 
> Please respond to this WG last call:
> 
> 
> * If you have no comments on the draft, and support its advancement,
>   simply respond with a line containing something like
> 
> 
>    "I support the advancement of this document to the IESG with a
>     request for publication as proposed standard."
> 
> 
>   If you have comments, please use a line similar to the one above,
>   and supplement this with your comments.
> 
> 
> 
> * If you *don't* support its advancement, respond with a line
>   containing something like the following, supplemented by your
> comments - 
> 
> 
>    "I don't support the advancement of this document to the IESG with
>     a request for publication as proposed standard, for the following
>     reasons:"
>    ...
> 
> 
> 
> 
>     Pete & Henrik

-- 
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: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Dec 2006 11:08:10 -0800

Jouni Korhonen wrote:
> Hi Vijay,
> 
> I think it was me who asked for this appendix. I'm happy to have it 
> there now. I'm not sure whether it makes any additional value to mention 
> in appendix A that the operator trusted network could also be 
> implemented as the home link from MNs. For certain wireless technologies 
> this would give a nice optimization.

We can add the following sentence at the end of the
appendix.

    When the mobile node is attached to the trusted access network, it
    can either by attached to a foreign link in the trusted network or to
    the home link directly.  This document does not impose any
    restrictions.

Vijay

> Apart from the above "I support the advancement of this document to the 
> IESG with a request for publication as proposed standard."
> 
> Cheers,
>     Jouni
> 
> Vijay Devarapalli kirjoitti:
>> just wanted to point out that the only major change
>> since the last WG last call was to add a new section
>> in the Appendix to show how the solution can be
>> applied to a mobile operator network.
>>
>> Vijay
>>
>>> describes a solution using Mobile IPv4 and mobility extensions to 
>>> IKEv2 (MOBIKE)
>>> to provide secure connectivity and mobility.
>>>
>>>   If you have comments, please use a line similar to the one above, and
>>>   supplement this with your comments.
>>>
>>>
>>>
>>> * If you *don't* support its advancement, respond with a line containing
>>>   something like the following, supplemented by your comments -
>>>
>>>

---

From: <[email-masked]>
Date: Mon, 11 Dec 2006 19:26:03 -0600

Hi Pete,

  I support progressing this document to the IESG with a
  request for publication as proposed standard.

-Rajeev

>-----Original Message-----
>From: ext McCann Peter-A001034 [mailto:[email-masked]] 
>Sent: Monday, December 11, 2006 7:23 AM
>To: [email-masked]
>Subject: RE: [Mip4] WGLC: draft-ietf-mip4-mobike-connectivity-01.txt
>
>Reminder: this WGLC ends tomorrow at midnight.  So far we have 
>gotten minimal feedback.  More support will be required to 
>advance this to the IESG.
>
>-Pete
>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 12 Dec 2006 13:31:22 +0200

Hi Vijay,

Vijay Devarapalli kirjoitti:
>> there now. I'm not sure whether it makes any additional value to 
>> mention in appendix A that the operator trusted network could also be 
>> implemented as the home link from MNs. For certain wireless 
>> technologies this would give a nice optimization.
> 

This is OK. Thanks.

> 
> Vijay
> 
> 
>> Apart from the above "I support the advancement of this document to 
>> the IESG with a request for publication as proposed standard."

So repeating myself ;)

"I support the advancement of this document to the IESG with a request 
for publication as proposed standard."

>>>> containing

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 12 Dec 2006 17:01:46 +0200

Dear WG participants,

I support the advancement of this document, as my comments to version -00 have been addressed.

One nit: the paragraph saying "Mobility extensions for IKEv2 are being standardized" should say "have been standardized" - MOBIKE is an RFC.

Thanks,
	Yaron

> From: McCann Peter-A001034 [mailto:[email-masked]]
> Sent: Monday, December 11, 2006 17:23
> To: [email-masked]

---

From: Hans Sjostrand <[email-masked]>
Date: Thu, 14 Dec 2006 15:04:46 +0100

Hi,

Sorry for being late. There are a few things in the draft that I would 
like to have clarified before agreeing to sending it to IESG.

1. Access mode home seams to be forgotten.

In figure 1 there is a access mode called {home}, but I can't find it 
described anywhere in the document. Is the access mode forgotten or 
omitted on purpose? Since the (in my experience) by far most common 
roaming case is a guy (or girl) leaving his desk for a wireless network 
it's really interesting. And most of the wireless networks are 
considered insecure. I'd really like some description and requirements 
for the home access mode before advancing the document.

2. Whats a few milliseconds worth?

In section 3.2 there is a line stating "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.". Apart from not complying with the RFC 2119 
keywords rules, I read it as a statement. The sending of a solicitation 
and waiting for an advertisements is normally a case of split seconds. 
Why start a DHCP cycle which only saves a couple of milliseconds an then 
rely on DHCP servers which normally introduces in order of magnitudes 
longer delays?

A "MAY" is of course ok to have for the really, really eager ones. 
Please add one for clarity.

3. Dual tunnel a normative reference

In my mind the references to the dual tunnel draft can't be considered 
as only informative. The internal/external detection is pretty central 
to this solution. And leaving the security consideration section to an 
informative draft I would assume is a bit OTT. It will be very hard to 
progress this draft through IESG without the dual tunnel draft also 
being advanced in the same time. Comments on that?

I've missed a lot of IETF meetings so I'm not that updated on the dual 
tunnel draft. Is the plans to advance it or scrap it? It's timed out in 
the draft repository. Have anyone implemented it? Sorry if I'm missing 
some obvious information or kicking in open doors. But I think it's 
relevant information in this context.

4. Movement detection and security.

In section 34. there is a sentence stating "Whenever the mobile node 
detects that it has moved to a new IP subnet [9] and its IP address 
changes". Again a lack of keywords. But I think this sentence is a 
potential security problem. It's not about subnets. It should be crystal 
clear that ANY detection of network movement whatsoever MUST result in a 
state that a security boundary may have been crossed and it sends a 
Registration Request to the i-HA.

5. Internet FA's

In this draft it seams that FA's on internet is silently ignored. 
Atleast those are not mentioned anyware that I find. I assume this is 
because the solution doesn't work with internet FA's. I think this is a 
limitation that might be worth mentioning.

Besides that, a good assumption is often a good idea.It's a bit hard to 
know of a FA is inside or outside. Thats why we wrote RFC3846. We have 
been using a RFC3846 agent NAI in  FA's to make an educated guess if 
it's a intranet FA or a internet FA. It's maybe therefore a good idea to 
reference RFC3846 "Mobile IPv4 Extension for Carrying Network Access 
Identifiers" and describe how agent NAIs could be used.

In our solution, if the suffix part of the FA NAI is known as an 
intranet identifier to the MN, then teh MN go against the i-HA.

Best regards
/// Hasse

---

From: Sami Vaarala <[email-masked]>
Date: Thu, 14 Dec 2006 16:48:10 +0200

Hi,

> relevant information in this context.

The draft has timed out because there haven't been any changes requested
since last revision - it's been basically sitting and waiting for WG
progress.  I haven't been attending late IETF meetings either so I'm not
really why the draft hasn't advanced in the WG.

BR,

-Sami

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 14 Dec 2006 19:31:30 +0100

Hi,

> really why the draft hasn't advanced in the WG.

The next thing to do is to do the Sheperd writeup and submit for publication.
It's just a matter of not finding the cycles to do this, and it is now
high on my list of things to do.

When we send in the request for publication, we'll ask for the current
draft to be made active again -- at least at this time I don't see a need
to re-submit the same text.

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 14 Dec 2006 14:31:52 -0800

Hans Sjostrand wrote:
> omitted on purpose? 

The {home} in the figure refers to the fact that the
link on which the i-HA is present is the home link.
It is not an access mode. There are only four access
modes even in draft-ietf-mip4-vpn-problem-solution.

> rely on DHCP servers which normally introduces in order of magnitudes 

Discovering a FA might take more than a few
milliseconds, especially if the FA does not send
out agent advertisements frequently and the mobile
node has to solicit for agents on the link. If the
mobile node is soliciting by sending agent
solicitations it can take upto 3 seconds before it
can conclude that there is no foreign agent on the
link.

> being advanced in the same time. Comments on that?

This makes sense. I don't remember why I had
draft-ietf-mip4-vpn-problem-solution as an
Informative reference. Could be because the status
of draft-ietf-mip4-vpn-problem-solution might have
been unknown.

> changes". Again a lack of keywords. 

This sentence just describes what the MN must do.
What would you like to see here?

> But I think this sentence is a 
> potential security problem. 

Can you elaborate a little bit more on the security
problem?

> It's not about subnets. It should be crystal 

Even when there is no subnet change? Why?

> limitation that might be worth mentioning.

If the mobile node does not have an external Home
Agent that it can reach when it is attached to an
untrusted network, it cannot obviously use the FA
on the untrusted network. If there is an external
home agent that it can use, then
draft-ietf-mip4-vpn-problem-solution would apply.

> intranet identifier to the MN, then teh MN go against the i-HA.

The Agent Advertisement is not protected. So I am
not sure we should be using the NAI extension from
RFC 3846, unless rogue foreign agents on a link are
not considered possible.

Another option is for the MN to always acquire a
CoA from the access network and send a registration
request to the i-HA. Once the MN detects that it is
attached to a trusted network, it can switch the FA
CoA mode if an FA is available on the trusted
network. Will this work for you?

Vijay

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 17 Dec 2006 13:06:17 +0200

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Friday, December 15, 2006 0:32
> To: Hans Sjostrand
> Cc: [email-masked]
> Subject: Re: [Mip4] Some comments on WGLC: draft-ietf-mip4-mobike-
> connectivity-01.txt
> 
> Hans Sjostrand wrote:
> > Hi,
> >
[...]
> Even when there is no subnet change? Why?
Because you can get an address on 192.168.0.0/16 from the enterprise DHCP server on the LAN, and immediately later another address on this subnet, or even the same one, from the untrusted WLAN (which uses a different NAT). This can be detected through layer-2 indications, but there are weirder cases when even that won't work.

Regards,
	Yaron

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 17 Dec 2006 11:30:53 -0800

> > because the solution doesn't work with internet FA's. I 
> think this is 
> > a limitation that might be worth mentioning.
> 
> If the mobile node does not have an external Home Agent that 
> it can reach when it is attached to an untrusted network, it 
> cannot obviously use the FA on the untrusted network. If 
> there is an external home agent that it can use, then 

This doesn't seem to make sense. This draft needs to talk about the
behavior of an MN that supports this solution. In this particular
solution, external FAs cannot be used. 

> > Besides that, a good assumption is often a good idea.It's a 
> bit hard 
> > to know of a FA is inside or outside. Thats why we wrote 
> RFC3846. We 
> > have been using a RFC3846 agent NAI in  FA's to make an 
> educated guess 
> > if it's a intranet FA or a internet FA. It's maybe therefore a good 
> > idea to reference RFC3846 "Mobile IPv4 Extension for 
> Carrying Network 
> > Access Identifiers" and describe how agent NAIs could be used.
> > 
> The Agent Advertisement is not protected. So I am not sure we 
> should be using the NAI extension from RFC 3846, unless rogue 
> foreign agents on a link are not considered possible.
> 
> Another option is for the MN to always acquire a CoA from the 
> access network and send a registration request to the i-HA. 
> Once the MN detects that it is attached to a trusted network, 
> it can switch the FA CoA mode if an FA is available on the 
> trusted network. Will this work for you?

This seems to be the only thing that will work for this draft. Here is
what I had said in one of my earlier emails to Henrik on this topic: 

"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. "

I think the draft can use some text on this. 

Vidya

---

From: Hans Sjostrand <[email-masked]>
Date: Mon, 18 Dec 2006 18:41:02 +0100

Hi Vijay,

some comments embedded.

Vijay Devarapalli wrote:
> Hans Sjostrand wrote:
>> Hi,
>>
>> Sorry for being late. There are a few things in the draft that I 
>> would like to have clarified before agreeing to sending it to IESG.
>>

I maintain that a mobile ip working document should describe the home 
mode. It's central and important. There are also other places where the 
FA and collocated away cases are described. But not the home case.

>> In section 3.2 there is a line stating "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.". Apart from not 
>> complying with the RFC 2119 keywords rules, I read it as a statement. 
>> The sending of a solicitation and waiting for an advertisements is 
>> normally a case of split seconds. Why start a DHCP cycle which only 
>> saves a couple of milliseconds an then rely on DHCP servers which 
>> normally introduces in order of magnitudes longer delays?
>

Firstly I don't think that a complimentary document should start 
defining MN behavior. That is regardless of handover performance. We 
should simple leave that to RFC3344. If you have concerns with handover 
performance and FA discovery, please take that in the RFC3344bis 
discussion. Do not write some new MN behavior in a complementary document.

A FA might for some reason not send out broadcast or multicast 
advertisements, thats true. But an FA SHOULD (section 2.3 in rfc3344) 
respond to Agent Solicitations. And a MN that doesn't solicitate on a 
new link seams a but passive in my mind, but thats implementation. In my 
experience a MN normally pics up a FA in almost notime.

> What would you like to see here?

Again, I don't think that we should define up new behaviors. RFC3344 
states.
-    A mobile node SHOULD initiate a registration whenever it detects a 
change in its network connectivity.

Thats pretty good for me. It's then up to each implementation to make 
it's own determination what "network connectivity" means.
>
>> But I think this sentence is a potential security problem. 
>

RFC4436 openly admits "In general, adjustment of the security 
configuration based on DNAv4 is NOT RECOMMENDED.". Therefore, assuming 
that they'll do the trick is a bit optimistic. I think there are quite a 
few security considerations to be elaborated here.

>
>> It's not about subnets. It should be crystal clear that ANY detection 
>> of network movement whatsoever MUST result in a state that a security 
>> boundary may have been crossed and it sends a Registration Request to 
>> the i-HA.
>

Assume that you are on a trusted network. And the computer associates 
with a new BSSID (i.e. a different AP than before). What would you have 
wanted your VPN vendor to do.
a) Accept the new nice AP that so kindly did let you in and continue to 
send clear text traffic.
b) Stop sending traffic until a registration procedure against the i-HA 
has made it clear that no security boundary has been passed.

My choice is clear. And I think the RFC4436 guys agree since they point 
out that arp and dhcp is NOT a security feature. Therefore, subnets are 
not the for making sure security boundaries are crossed or not.

>> because the solution doesn't work with internet FA's. I think this is 

There are no external home agent in this context. Atleast not in the 
terminology the solutions part of the document that I read through. It 
was just a suggestion to be fair to readers of this document that an 
internet FA is unusable and if one is detected it should discarded as a 
possible agent. Not a big thing.

>
>> Besides that, a good assumption is often a good idea.It's a bit hard 
>> to know of a FA is inside or outside. Thats why we wrote RFC3846. We 
>> have been using a RFC3846 agent NAI in  FA's to make an educated 
>> guess if it's a intranet FA or a internet FA. It's maybe therefore a 
>> good idea to reference RFC3846 "Mobile IPv4 Extension for Carrying 
>> Network Access Identifiers" and describe how agent NAIs could be used.
>>
I know that advertisements isn't protected, thats why I sued works like 
"assumption" and "educated guess". This was probably more 
implementation. A smart implementation could make assumptions and 
educated guesses but it's ok for me to leave it at that.

Please, no new requirements for MN behavior to acquire a CoA or not.

Regards

/// Hasse

---

From: Hans Sjostrand <[email-masked]>
Date: Mon, 18 Dec 2006 19:00:15 +0100

Comments in the end.

> I think the draft can use some text on this. 

Formally you are right Vidya. Thats why I thought it was a good idea to 
introduce an "educated guess".

If you, for example via RFC3846 advertisements, recognize that you most 
probably are inside you could start by registering with the i-HA. And 
vice versa, if you make an educated guess that your outside, then you 
could start of by doing a VPN tunnel.

This is however completely informational and it's only about handover 
performance. It's only the IKE mobility exchange and the MIP 
registration exchange that is valid indications of actual location and 
security policy to apply.

We should not mandate behavior here, the specification should be open 
for implementation.

Best regards
/// Hasse

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 18 Dec 2006 13:19:39 -0800

> From: Hans Sjostrand [mailto:[email-masked]] 
> Sent: Monday, December 18, 2006 10:00 AM
> To: Narayanan, Vidya
> Cc: [email-masked]; Vijay Devarapalli
> Subject: Re: [Mip4] Some comments on 
> WGLC:draft-ietf-mip4-mobike-connectivity-01.txt
> 
> Comments in the end.
> 
> >> The Agent Advertisement is not protected. So I am not sure 
> we should 
> >> be using the NAI extension from RFC 3846, unless rogue 
> foreign agents 
> >> Another option is for the MN to always acquire a CoA from 
> the access 
> >> network and send a registration request to the i-HA.
> >> Once the MN detects that it is attached to a trusted 
> network, it can 
> >> switch the FA CoA mode if an FA is available on the 
> trusted network. 
> >> Will this work for you?
> >>     
> >
> > 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. "
> >
> Formally you are right Vidya. Thats why I thought it was a 
> good idea to introduce an "educated guess".
> 
> If you, for example via RFC3846 advertisements, recognize 
> that you most probably are inside you could start by 
> registering with the i-HA. And vice versa, if you make an 
> educated guess that your outside, then you could start of by 
> doing a VPN tunnel.
> 

The problem is that if there are any statements about using
RFC3846-style FAAs, the document also has to talk about security issues
with masquerading FAs. I'm not sure that is worth getting into. But, I'd
be fine with such text, as long as the security implications are
appropriately pointed out. 

Regards,
Vidya

> This is however completely informational and it's only about 
> handover performance. It's only the IKE mobility exchange and 
> the MIP registration exchange that is valid indications of 
> actual location and security policy to apply.
> 
> We should not mandate behavior here, the specification should 
> be open for implementation.
> 
> Best regards
> /// Hasse
> 
> 
> 
> 
> 
> --

---

From: Hans Sjostrand <[email-masked]>
Date: Mon, 18 Dec 2006 22:38:04 +0100

> appropriately pointed out. 

It wasn't a good idea at all to mix implementation and specification. 
I'll simply pull back anything I've proposed along with "Besides that, a 
good assumption is often a good idea....." It will just confuse people 
and possibly delay the draft.

What matters is that the draft doesn't prevent these things by 
overspecifying the order events of which things could be made. Then I'm 
happy.

Best regards
/// Hasse

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Dec 2006 11:59:03 -0800

Hi Yaron,

> Because you can get an address on 192.168.0.0/16 from the enterprise DHCP server on the LAN, and immediately later another address on this subnet, or even the same one, from the untrusted WLAN (whi…

Implicit in my reply was that DNAv4 (RFC 4436) is
used for movement detection. With DNAv4, the mobile
node will be able to detect movement to another subnet
for the scenario you mention above.

Hans Sjostrand wrote:
>>>
>>> In section 34. there is a sentence stating "Whenever the mobile node detects that it has moved to a new IP subnet [9] and its IP address changes". Again a lack of keywords. 
> Again, I don't think that we should define up new behaviors. RFC3344 states.
> -    A mobile node SHOULD initiate a registration whenever it detects a change in its network connectivity.
> 
> Thats pretty good for me. It's then up to each implementation to make it's own determination what "network connectivity" means.

>>
>>> It's not about subnets. It should be crystal clear that ANY detection of network movement whatsoever MUST result in a state that a security boundary may have been crossed and it sends a Registration Request to the i-HA.
>>
> Assume that you are on a trusted network. And the computer associates with a new BSSID (i.e. a different AP than before). What would you have wanted your VPN vendor to do.
> a) Accept the new nice AP that so kindly did let you in and continue to send clear text traffic.
> b) Stop sending traffic until a registration procedure against the i-HA has made it clear that no security boundary has been passed.
> 
> My choice is clear. And I think the RFC4436 guys agree since they point out that arp and dhcp is NOT a security feature. Therefore, subnets are not the for making sure security boundaries are crossed or not. 

Ok. We will go with what 3344 says. Here is the new
text in section 3.4

    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 a change in network connectivity, it sends a
    Registration Request to the i-HA without any VPN encapsulation.

This will also remove the reference to RFC 4436.

Vijay