Reminder: Working Group Last Call fordraft-ietf-mip4-mobike-connectivity-00]

Hi Vijay,

Yes, parallel operation i.e. RRQ and MOBIKE seems to
mitigate the setup
delay concern. 

I see that you mention about RRQ over the VPN tunnel in
addition to the
one sent in clear text to i-HA. Are these two RRQs sent in
parallel as
per this I-D? Also, in your I-D there is no mention of x-HA
as in the
VPN problem solution I-D. So, it seems the MN will send the
RRQ over the
VPN tunnel to the same HA (i-HA) apart from the RRQ sent in
clear text.
If sent in parallel, and if the MN is in a trusted domain,
this will
result in two back-to-back RRPs. This is not a major
concern, but it
seems to generate some extra traffic/transactions.

-Kuntal

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijay.devarapalliazairenet.com]
> Sent: Thursday, April 27, 2006 7:29 PM
> To: Chowdhury, Kuntal
> Cc: Henrik Levkowetz; MIP4 Mailing list
> Subject: Re: [Mip4] Reminder: Working Group Last Call
fordraft-ietf-mip4-
> mobike-connectivity-00]
> 
> hi Kuntal,
> 
> Chowdhury, Kuntal wrote:
> > Hi,
> >
> > The document looks OK to me. So it should progress
as intended.
> >
> > One comment: having the MN send MIPv4 registration
request outside
of
> > the VPN tunnel may increase setup time. This will
happen if the MN
has
> > moved into an un-trusted network.
> 
> the MOBIKE update message and the registration
> request without VPN encapsulation to i-HA
> will be done in parallel. if the i-HA replies
> with a registration reply, then it means the
> MN is attached to the trusted network.
> 
> > If the MN has a VPN tunnel, why not having it send
MIP4 RRQ over the
VPN
> > tunnel?
> 
> once the MOBIKE update is done, a registration
> request is sent over the VPN tunnel too.
> 
> security boundary detection based on i-HA
> reachability is described in more detail in
> draft-ietf-mip4-vpn-problem-solution-02.txt.
> see section 3.3.
> 
> Vijay



-- 
Mip4 mailing list: Mip4ietf.org
    Web interface: https://w
ww1.ietf.org/mailman/listinfo/mip4
     Charter page: h
ttp://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

hi Kuntal,

Chowdhury, Kuntal wrote:
> Hi Vijay,
> 
> Yes, parallel operation i.e. RRQ and MOBIKE seems to
mitigate the setup
> delay concern. 
> 
> I see that you mention about RRQ over the VPN tunnel in
addition to the
> one sent in clear text to i-HA. Are these two RRQs sent
in parallel as
> per this I-D? 

yes.

> Also, in your I-D there is no mention of x-HA as in the
> VPN problem solution I-D. 

right, because MOBIKE is used to handle mobility
when the mobile node is outside the enterprise.

> So, it seems the MN will send the RRQ over the
> VPN tunnel to the same HA (i-HA) apart from the RRQ
sent in clear text.
> If sent in parallel, and if the MN is in a trusted
domain, this will
> result in two back-to-back RRPs. This is not a major
concern, but it
> seems to generate some extra traffic/transactions.

correct. but this is one mechanism to check whether
the mobile node is attached to a trusted/untrusted
network. if there is a better mechanism available
in a particular deployment, I think that should be
used over this.

Vijay

> 
> -Kuntal
> 
>> -----Original Message-----
>> From: Vijay Devarapalli
[mailto:vijay.devarapalliazairenet.com]
>> Sent: Thursday, April 27, 2006 7:29 PM
>> To: Chowdhury, Kuntal
>> Cc: Henrik Levkowetz; MIP4 Mailing list
>> Subject: Re: [Mip4] Reminder: Working Group Last
Call
> fordraft-ietf-mip4-
>> mobike-connectivity-00]
>>
>> hi Kuntal,
>>
>> Chowdhury, Kuntal wrote:
>>> Hi,
>>>
>>> The document looks OK to me. So it should
progress as intended.
>>>
>>> One comment: having the MN send MIPv4
registration request outside
> of
>>> the VPN tunnel may increase setup time. This
will happen if the MN
> has
>>> moved into an un-trusted network.
>> the MOBIKE update message and the registration
>> request without VPN encapsulation to i-HA
>> will be done in parallel. if the i-HA replies
>> with a registration reply, then it means the
>> MN is attached to the trusted network.
>>
>>> If the MN has a VPN tunnel, why not having it
send MIP4 RRQ over the
> VPN
>>> tunnel?
>> once the MOBIKE update is done, a registration
>> request is sent over the VPN tunnel too.
>>
>> security boundary detection based on i-HA
>> reachability is described in more detail in
>> draft-ietf-mip4-vpn-problem-solution-02.txt.
>> see section 3.3.
>>
>> Vijay
> 
> 
> 
> "This email message and any attachments are
confidential information of Starent Networks, Corp. The
information transmitted may not be used to create or change
any contractual obligations of Starent Networks, Corp.  Any
review, retransmission, dissemination or other use of, or
taking of any action in reliance upon this e-mail and its
attachments by persons or entities other than the intended
recipient is prohibited. If you are not the intended
recipient, please notify the sender immediately -- by
replying to this message or by sending an email to
postmasterstarentnetworks.com -- and destroy all copies of this
message and any attachments without reading or disclosing
their contents. Thank you."


-- 
Mip4 mailing list: Mip4ietf.org
    Web interface: https://w
ww1.ietf.org/mailman/listinfo/mip4
     Charter page: h
ttp://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/