Re: [MEXT] AD review of draft-ietf-mext-flow-binding

Hi Jari,

Thanks for the review and the comments, all of which I deal with below.
I am publishing the new ID immediately incorporating all of the
corrections/additions below, but let me know if there is anything else
we need to change.

George

On Fri, Feb 26, 2010 at 11:59 AM, Jari Arkko <jari.arkko <at> piuha.net> wrote:
> I have reviewed this specification. It is basically in very good shape, but
> I did detect a few small issues. Please correct them so that I can last call
> the document:
>
> Mobile nodes supporting this specification MUST use the BID option
> format defined in Section 4.1.  Mobile nodes MUST also register all
> care-of addresses using the updated BID option format, either in the
> same BU as any flow identification mobility options using them, or in
> earlier BUs.
>
>
> Can you talk about what the backwards compatibility issues with the
> additional PRI field are somewhere? I am assuming that 0 in a reserved field
> is ignored, and new nodes will treat PRI 0 as a sign that its an old format
> BID option.
>

GT> I am adding the following:
                   <t>To ensure backwards compatibility with <xref
                           target="RFC5648"/> for the purpose of this

[MEXT] I-D Action:draft-ietf-mext-flow-binding-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : Flow Bindings in Mobile IPv6 and NEMO Basic Support
	Author(s)       : H. Soliman, et al.
	Filename        : draft-ietf-mext-flow-binding-06.txt
	Pages           : 39
	Date            : 2010-03-01

This document introduces extensions to Mobile IPv6 that allow nodes
to bind one or more flows to a care-of address.  These extensions
allow multihomed nodes to instruct home agents and other Mobile IPv6
entities to direct inbound flows to specific addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
MEXT mailing list
MEXT <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext

[MEXT] FW: I-D Action:draft-jeyatharan-mext-flow-tftemp-reference-00.txt

Hi all,

We have submitted a draft called: 
draft-jeyatharan-mext-flow-tftemp-reference-00.txt.

It is about using 3gpp traffic flow template (TFT) as a reference to
flow in the flow binding process.

Any comments are appreciated.

BR,
Mohana 
-----Original Message-----
From: i-d-announce-bounces <at> ietf.org
[mailto:i-d-announce-bounces <at> ietf.org] On Behalf Of
Internet-Drafts <at> ietf.org
Sent: Tuesday, March 02, 2010 8:30 AM
To: i-d-announce <at> ietf.org
Subject: I-D Action:draft-jeyatharan-mext-flow-tftemp-reference-00.txt 

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

	Title           : 3GPP TFT Reference for Flow Binding
	Author(s)       : M. Jeyatharan, C. Ng
	Filename        :
draft-jeyatharan-mext-flow-tftemp-reference-00.txt
	Pages           : 10
	Date            : 2010-03-01

[MEXT] Rethink on Mobile IPv6

Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack
Mobile IPv6 (RFC5555) since 2009. Implementations of the protocol has
been lacklustre to say the least. Several SDOs have considered MIP6
and DSMIP6 as a solution for interworking and mobility between
different access technologies and only 3GPP has adopted it in a very
limited manner for Rel 8 (for use on the S2c interface) with the
likelihood of it being actually deployed quite low (IMO).

While there are many reasons that can be attributed to the lack of
implementations and use, one that I would like to raise is the the
concern with the overly complex security model that MIP6/DSMIP6 relies
on today. MIP6/DSMIP6 requires IPsec and IKE/IKEv2 (RFC3776/4877) to
secure the signaling between the MN and HA. The fundamental purpose of
MIP6/DSMIP6 is to provide mobility to hosts. At a very high level the
MIP6/DSMIP6 protocol boils down to the ability to setup a tunnel
between the MN and HA and update the MN tunnel end-point whenever
there is a change in the associated IP address (CoA). The signaling to
establish the tunnel needs to be secure. But using a protocol like
IKEv2 and IPsec to achieve this security is just an overkill. It
increases the complexity of the implementation as a result of many
factors that have been captured in I-D:
draft-patil-mext-mip6issueswithipsec and discussed in the MEXT WG
meetings. 

Given the objective of the protocol is to enable IP mobility for hosts,
it should focus on doing that well in a manner that makes it easy to
implement/adopt/deploy/scale. My opinion as a result of implementation
experience is that MIP6/DSMIP6 can be significantly simplified,
especially the security architecture. The protocol as specified

Re: [MEXT] Rethink on Mobile IPv6

Hi,

with some salt ...

<Basavaraj.Patil <at> nokia.com> writes:

> Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack
> Mobile IPv6 (RFC5555) since 2009. Implementations of the protocol has
> been lacklustre to say the least. Several SDOs have considered MIP6
> and DSMIP6 as a solution for interworking and mobility between
> different access technologies and only 3GPP has adopted it in a very
> limited manner for Rel 8 (for use on the S2c interface) with the
> likelihood of it being actually deployed quite low (IMO).
>
> While there are many reasons that can be attributed to the lack of
> implementations and use, one that I would like to raise is the the
> concern with the overly complex security model that MIP6/DSMIP6 relies
> on today. MIP6/DSMIP6 requires IPsec and IKE/IKEv2 (RFC3776/4877) to
> secure the signaling between the MN and HA. The fundamental purpose of
> MIP6/DSMIP6 is to provide mobility to hosts. At a very high level the
> MIP6/DSMIP6 protocol boils down to the ability to setup a tunnel
> between the MN and HA and update the MN tunnel end-point whenever
> there is a change in the associated IP address (CoA). The signaling to
> establish the tunnel needs to be secure. But using a protocol like
> IKEv2 and IPsec to achieve this security is just an overkill. It
> increases the complexity of the implementation as a result of many
> factors that have been captured in I-D:
> draft-patil-mext-mip6issueswithipsec and discussed in the MEXT WG
> meetings. 
>

Re: [MEXT] [Int-area] Rethink on Mobile IPv6

While I support the philosophy that IPsec and IKE(v2) are the core 
security solution for most IP layer requirements, I agree with your 
contention that it is a heavyweight solution presenting a barrier to 
entry for mobility devices.  The only thing that keeps me from agreeing 
without reservation is that any alternative method must peacefully 
coexist with RFC4877.  In other words, it should be possible for a HA 
and MN to detect/negotiate whether MIP6lite or RFC4877 is supported.  
Thus it becomes a choice for the end-user:  build a network with the 
appropriate level of security (none, MIP6lite, RFC4877) by selecting the 
products that support the required level.  Ideally a HA would support 
both to accommodate both types of MNs.

Also, to be truly useful, MIP6lite must be simple, modular and timely - 
i.e. solve the basic problem soon with "better than nothing" security, 
with the ability to be extended with more protection, perhaps even up to 
the level of RFC4877, as needed.  We don't need yet another long process 
attempting to solve all the problems before anything happens, but 
something well-defined and constrained to enable an entry-level secure MIP6

I don't know if I have much to offer in contribution, but this is 
something I would be interested in, and support as a reviewer as it 
evolves.  If done in a timely fashion, it would remove an obstacle to 
the wider adoption of MIP6 with a reduced but appropriate level of security.

Might I suggest sMIP6 (simple/secure MIP6) as a name? 

Ed J.
On 3/3/2010 10:55 AM, Basavaraj.Patil <at> nokia.com wrote:
> Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack
>

[MEXT] FW: request for help in developing a tool that may be helpful to WG chairs

FYI - 

-----Original Message-----
From: wgchairs-bounces <at> ietf.org [mailto:wgchairs-bounces <at> ietf.org] On Behalf Of Scott O. Bradner
Sent: Wednesday, March 03, 2010 7:36 AM
To: wgchairs <at> ietf.org
Subject: request for help in developing a tool that may be helpful to WG chairs

IETF working group chairs;

We are developing an open-source tool for monitoring the status and
progress of conflicts in on-line working groups (WG).  The tool works by
analyzing the WG mailing list.  When developed, this tool should be
helpful to WG chairs trying to understand the status of WG discussions
(how close to consensus is the WG, what is the distribution of
participation, etc).

As part of the development process we have been using a prototype tool
to analyze IETF WG mailing list archives to determine the amount of
conflict and how effective this conflict is being (has been) resolved.
As the first step, we need to understand the relationship between the
conflicts in a working group and the structure of the communication
network in that group. While having conflicts is not necessarily a bad
thing for a working group effort, some conflicts can escalate into
disasters. We are interested in finding the communication patterns
related to the evolution of group conflicts. Results from this study
will provide the base for the development of the tool that helps working
group chairs to decide when to intervene with an internal conflict
before it becomes irreversibly negative as well as being a tool that may
help determine where there is consensus on a particular topic.

Re: [MEXT] [Int-area] Rethink on Mobile IPv6

_______________________________________________
MEXT mailing list
MEXT <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext

Re: [MEXT] [Int-area] Rethink on Mobile IPv6

I agree that a discovery procedure is useful BUT
>
>
> I agree 100%!  Without something that can actually interoperate "out 
> of the box" with another vendor's systems, it becomes almost 
> impossible _to deploy in a large heterogeneous systems space where you 
> have no control of the link's other end.
> _
>

This is not necessarily true. There no absolute need to have 
interoperability between the MN and the HA unless you want a Mobile IP 
client to work with a random HA. There are examples today where this is 
also desired but not necessary to get a huge amount of deployment, such 
as IM clients and VPNs. If you look around what different SDOs have done 
with mobile IP then you will notice that everyone came up with different 
key derivation mechanisms (some call it "bootstrapping"). This pure fact 
makes Mobile IP clients non interoperable beyond SDOs.

If you make it sufficiently easy to install the client software then an 
operator can very easily ship a client to you.

Just some random thoughts....

Ciao
Hannes

Re: [MEXT] [Int-area] Rethink on Mobile IPv6

I think I basically agree with Terry, though I do have
a little bit different perspective.

It's become commonplace with many protocols to define
"profiles" that tailor the bells-and-whistles and other
configuration parameters that an implementation needs to
include for a specific environment.  I've always assumed
that this would be the case for aeronautics in order to
bound the level of conformance testing required and ensure
full compatibility.

In some sense, the IETF already does this with MUST, MAY,
SHOULD language in our documents, as the MUSTs define
a minimal profile.  However, this is often not really
minimal enough for some people, and to further complicate
matters, it tends not to be enough to do a lot of what
people really want.  So we have a persistent problem
in understanding how to add features onto the base
with all of the proper dependencies as the text in RFCs
doesn't indicate the linkages between pieces of one
document with multiple other documents as clearly as a
database system might.

Going down this path of profiles can quickly lead to
profiles developed for different user communities
becoming incompatible to the point where the advantages
of having a common protocol and commodity providers and
implementations are lost.  Hannes mentioned that
having an operator ship you software is possible, but
in an air or space environment where you need cross
support, that's not really feasible nor is it really
sustainable long-term for such smaller user communities.

So what I think Basavaraj and others have argued for is
a minimal MIPv6 profile where IKE is not necessary, and
perhaps other parts of IPsec aren't either.  The
challenge is to define this such that not only can it
live in conjunction on the network with RFC 4877
compliant hosts, but also can be built-up with
capabilities in a well-understood way rather than by
drawing from a grab bag of options and extension headers.
It's possible that one way of building-it-up would be to
replace the minimal security mechanisms it would have
with the heavier-weight mechanisms like IKE & IPsec.

--
Wes Eddy
MTI Systems

>-----Original Message-----
>From: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] On Behalf Of
>Davis, Terry L
>Sent: Wednesday, March 03, 2010 2:31 PM
>To: 'Ed Jankiewicz'; Basavaraj.Patil <at> nokia.com
>Cc: mext <at> ietf.org; int-area <at> ietf.org; rdroms <at> cisco.com
>Subject: Re: [MEXT] [Int-area] Rethink on Mobile IPv6
>
>Ed/Basavarai
>
>I agree 100%!  Without something that can actually interoperate "out of
>the box" with another vendor's systems, it becomes almost impossible to
>deploy in a large heterogeneous systems space where you have no control
>of the link's other end.
>
>At least some of us in the aviation space find ourselves in a quandary
>as we ponder how to try to implement IPSec with Mobility (or actually
>even without mobility in ground systems).  Every vendor that ever made
>"one of whatever" we have in the global aviation environment to deal
>with! In some scenarios, especially for international operations in the
>future, an aircraft utilizes more than half dozen communication service
>providers and sets up links through them with a similar number of
>different air traffic control centers during a single flight.  And the
>next flight is likely with at least a different set of centers.
>
>The CI sectors I understand are starting to see similar problems too.
>
>I suppose we could have managed to build in more "non"-interoperability
>into IPSec but then maybe we succeeded as the associated PKI has similar
>implementation problems between different CAs.
>
>I actually think the problem started with the designers assumption that
>the user controlled both ends of the link being secured.  In reality
>this is becoming less and less the case as we work more and more
>globally.
>
>sMIP6 would be a good start!
>
>Take care
>Terry
>
>PS: Maybe if I'd been a better/louder "hummer" simpler might have been
>here already.
>
>> -----Original Message-----
>> From: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] On
>> Behalf Of Ed Jankiewicz
>> Sent: Wednesday, March 03, 2010 9:36 AM
>> To: Basavaraj.Patil <at> nokia.com
>> Cc: rdroms <at> cisco.com; int-area <at> ietf.org; mext <at> ietf.org
>> Subject: Re: [MEXT] [Int-area] Rethink on Mobile IPv6
>>
>> While I support the philosophy that IPsec and IKE(v2) are the core
>> security solution for most IP layer requirements, I agree with your
>> contention that it is a heavyweight solution presenting a barrier to
>> entry for mobility devices.  The only thing that keeps me
>> from agreeing
>> without reservation is that any alternative method must peacefully
>> coexist with RFC4877.  In other words, it should be possible for a HA
>> and MN to detect/negotiate whether MIP6lite or RFC4877 is supported.
>> Thus it becomes a choice for the end-user:  build a network with the
>> appropriate level of security (none, MIP6lite, RFC4877) by
>> selecting the
>> products that support the required level.  Ideally a HA would support
>> both to accommodate both types of MNs.
>>
>> Also, to be truly useful, MIP6lite must be simple, modular
>> and timely -
>> i.e. solve the basic problem soon with "better than nothing"
>> security,
>> with the ability to be extended with more protection, perhaps
>> even up to
>> the level of RFC4877, as needed.  We don't need yet another
>> long process
>> attempting to solve all the problems before anything happens, but
>> something well-defined and constrained to enable an
>> entry-level secure MIP6
>>
>> I don't know if I have much to offer in contribution, but this is
>> something I would be interested in, and support as a reviewer as it
>> evolves.  If done in a timely fashion, it would remove an obstacle to
>> the wider adoption of MIP6 with a reduced but appropriate
>> level of security.
>>
>> Might I suggest sMIP6 (simple/secure MIP6) as a name?
>>
>> Ed J.
>> On 3/3/2010 10:55 AM, Basavaraj.Patil <at> nokia.com wrote:
>> > Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack
>> >
>> > -Basavaraj
>> >
>> > _______________________________________________
>> > Int-area mailing list
>> > Int-area <at> ietf.org
>> > https://www.ietf.org/mailman/listinfo/int-area
>> >
>> >
>>
>> _______________________________________________
>> MEXT mailing list
>> MEXT <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>>