Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements

From: Brian Haberman <[email-masked]>
Date: Fri, 24 Jan 2014 12:29:46 -0500

All,
     I have performed my AD review, as a part of the publication
process, of draft-ietf-dmm-requirements.  The following issues should be
addressed prior to moving this draft to IETF Last Call.  Please let me
know if you have any questions on these points.

1. I would suggest making sure that the Abstract and Introduction
explicitly state that these requirements for for network (L3)-layer
mobility management.

2. Introduction:

- The EPC acronym needs to be expanded.
- Do not reference the DMM charter within the document.
- expand HA and LMA since you are using them before the Terminology section.

3. Section 3:

- It would be nice to ensure that all acronyms used in the figures are
expanded somewhere prior to the figures.

- I am curious as to why there is not any mention in this section about
route optimization within the mobility protocols.  This mention should
describe why current route optimization is host-based in order to lead
into PS1.

4. Section 4:

- To be abundantly clear, I would re-word the start of PS3 to be "Lack
of scalability".

- I am not sure that it benefits the document to label PS6 and PS7 as
related.  Those issues are problematic on their own.  If you remove the
"(related problem)" label from them, make sure that REQ2 is updated to
remove mention of "related problem".

- Should PS7 mention mobility solutions that operated at other layers of
the protocol stack?

5. Section 5:

- Why does this section have sub-section numbers AND REQ numbers?

- I am not sure I understand what REQ1 is saying when it talks about
combining mobility anchors with CDNs.  It *sounds* like mobility
management needs to be maintained by CDN providers.

- I am a little confused by REQ2.  It says that a DMM solution should be
transparent to the applications.  However, the motivation talks about
identifying applications that do (or do not) need mobility support from
the network layer.  That doesn't sound transparent to me.  Am I reading
this incorrectly?

- I am wondering if the SHOULD in REQ4 ought to be a MUST.  Why would
anyone work on a new protocol without first determining the feasibility
of the existing ones?

- What is meant by co-exist in REQ5?  Does this mean that a DMM solution
does not break an existing one?  Or does it mean that it must
inter-operate with existing ones?  Is this like IPv4 and IPv6 being
incompatible, but can run concurrently on the same network?  Or does
this mean there needs to be some mechanism for interaction (i.e., like
NAT64)?

- I think REQ6 is incomplete.  A DMM solution can introduce new
vulnerabilities, but it needs to provide ways to cope with those
vulnerabilities.

6. I would like to avoid issues further along the publication chain, so
I would like the editors to look at how the contributing authors are
identified in the draft.  A good approach is described in the RFC Style
Guide (https://www.rfc-editor.org/policy.html#policy.auth) and deviating
from that can be problematic.

Regards,
Brian

---

From: h chan <[email-masked]>
Date: Sat, 25 Jan 2014 00:38:34 +0000

4. Section 4:
- I am not sure that it benefits the document to label PS6 and PS7 as related.  Those issues are problematic on their own.  If you remove the "(related problem)" label from them, make sure that REQ2 is updated to remove mention of "related problem".

The intention of the name "related problems" was not to suggest they are less problematic, but rather to distinguish them from the other problems directly on mobility management. Although these problems are not directly on mobility management, the DMM solutions can solve these additional problems. They are therefore included. So, as long as this section is not to be interpreted as limited to problems directly on mobility management, we can drop the word "related."

H Anthony Chan

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Friday, January 24, 2014 11:30 AM
To: [email-masked]; [email-masked]; Peter McCann
Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements

All,
     I have performed my AD review, as a part of the publication process, of draft-ietf-dmm-requirements.  The following issues should be addressed prior to moving this draft to IETF Last Call.  Please let me know if you have any questions on these points.

1. I would suggest making sure that the Abstract and Introduction explicitly state that these requirements for for network (L3)-layer mobility management.

2. Introduction:

3. Section 3:

- It would be nice to ensure that all acronyms used in the figures are expanded somewhere prior to the figures.

- I am curious as to why there is not any mention in this section about route optimization within the mobility protocols.  This mention should describe why current route optimization is host-based in order to lead into PS1.

4. Section 4:

- To be abundantly clear, I would re-word the start of PS3 to be "Lack of scalability".

- I am not sure that it benefits the document to label PS6 and PS7 as related.  Those issues are problematic on their own.  If you remove the "(related problem)" label from them, make sure that REQ2 is updated to remove mention of "related problem".

- Should PS7 mention mobility solutions that operated at other layers of the protocol stack?

5. Section 5:

- I am not sure I understand what REQ1 is saying when it talks about combining mobility anchors with CDNs.  It *sounds* like mobility management needs to be maintained by CDN providers.

- I am a little confused by REQ2.  It says that a DMM solution should be transparent to the applications.  However, the motivation talks about identifying applications that do (or do not) need mobility support from the network layer.  That doesn't sound transparent to me.  Am I reading this incorrectly?

- I am wondering if the SHOULD in REQ4 ought to be a MUST.  Why would anyone work on a new protocol without first determining the feasibility of the existing ones?

- What is meant by co-exist in REQ5?  Does this mean that a DMM solution does not break an existing one?  Or does it mean that it must inter-operate with existing ones?  Is this like IPv4 and IPv6 being incompatible, but can run concurrently on the same network?  Or does this mean there needs to be some mechanism for interaction (i.e., like NAT64)?

- I think REQ6 is incomplete.  A DMM solution can introduce new vulnerabilities, but it needs to provide ways to cope with those vulnerabilities.

6. I would like to avoid issues further along the publication chain, so I would like the editors to look at how the contributing authors are identified in the draft.  A good approach is described in the RFC Style Guide (https://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can be problematic.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Mon, 27 Jan 2014 08:20:14 -0500

On 1/24/14 7:38 PM, h chan wrote:
> 4. Section 4: - I am not sure that it benefits the document to label
> PS6 and PS7 as related.  Those issues are problematic on their own.
> If you remove the "(related problem)" label from them, make sure that
> REQ2 is updated to remove mention of "related problem".
> 
> The intention of the name "related problems" was not to suggest they
> are less problematic, but rather to distinguish them from the other
> problems directly on mobility management. Although these problems are
> not directly on mobility management, the DMM solutions can solve
> these additional problems. They are therefore included. So, as long
> as this section is not to be interpreted as limited to problems
> directly on mobility management, we can drop the word "related."
> 

I will leave it to the authors/WG, but I don't see a benefit to the
"related" tag.

Regards,
Brian

---

From: h chan <[email-masked]>
Date: Tue, 28 Jan 2014 01:45:33 +0000

I will drop "related"

Regarding the following

5. Section 5:

It appears that unless the network can find out whether the application has need of such support, the application indeed may need to invoke mobility support or has to convey its need to the network. 

The emphasis of requirement is on "when needed." So, I think it is better to drop the word "transparent" as follows:

   REQ2:  Mobility support when needed

          DMM solutions MUST provide mobility support to above
          the IP layer when needed.  Such support is needed, for
          example, when, upon change of point of attachment to the
          network, an application flow cannot cope with a change in the
          IP address.  However, it is not always necessary to maintain a
          stable home IP address or prefix for every application or at
          all times for a mobile node.

          Motivation: The motivation of this requirement is to enable
          more efficient routing and more efficient use of network
          resources by selecting an IP address or prefix according to
          whether mobility support is needed and by not maintaining
          context at the mobility anchor when there is no such need.

H Anthony Chan

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Monday, January 27, 2014 7:20 AM
To: h chan; [email-masked]; [email-masked]; Peter McCann
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

On 1/24/14 7:38 PM, h chan wrote:
> not directly on mobility management, the DMM solutions can solve these 
> additional problems. They are therefore included. So, as long as this 
> section is not to be interpreted as limited to problems directly on 
> mobility management, we can drop the word "related."
> 

I will leave it to the authors/WG, but I don't see a benefit to the "related" tag.

Regards,
Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Jan 2014 15:42:41 +0100

Le 28/01/2014 02:45, h chan a écrit :
> I will drop "related"
>
> Regarding the following
>
> 5. Section 5:
> - I am a little confused by REQ2.  It says that a DMM solution should be transparent to the applications.

This remark is typically true when we talk Mobile IP on a Mobile Host 
and an application like firefox runs above a BSD Socket interface.

> However, the motivation talks about identifying applications that do (or do not) need mobility support from the network layer.  That doesn't sound transparent to me.  Am I reading this incorrectly?
>

Whenever we discuss this 'transparency' paragraph I have again the same 
comments.

First, I am not sure DMM is only about Mobile Hosts, or about Mobile 
Routers as well.

Because, if we talk Mobile Routers, then rarely an application runs 
directly on it.  Most applications would run on LFN.

Transparency?

If the applications run on the LFN, the change of the attachment of the 
MR is 'transparent' to them, regardless whether or not MR does something 
to maintain stability of that address (Mobile IP, other).

Second, this transparency may depend on the direction, or more complex 
'shape' of the application flows.  Some IP flows of some applications 
have very complex 'shapes', with various sets of IP src and dst, and 
triangular or HA-less shapes.

Take for example a video-call.  The session establishment through an 
intermediary and behind NAT is followed by the ongoing 4 flows (2 audio 
2 video)... they all take different paths... each may need or not need 
to go through the HA, and each has distinct behaviours when the IP 
address changes, hence each would have a distinct 'transparency' 
requirement.  Is this _one_ application?

Alex

> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>
>

---

From: h chan <[email-masked]>
Date: Tue, 28 Jan 2014 18:58:24 +0000

Let me try to understand the concern here. 

What is new in this requirement is "when needed" in contrast to providing IP mobility by default.

Without this requirement, mobility support may be provided by default, which is transparent to higher layers. 

With this requirement, assume there are separate steps in the DMM solution. 
1. A decision is made whether network-layer mobility support is needed.
2. When the need is established, network-layer mobility support is invoked.
3. Then transparent support is provided and is transparent to layers above IP.

Transparency is clear in step 3 above.

The question however is whether the preceding steps involve the application, so that one may question whether the entire DMM solution (with all the steps) as a whole is transparent.

So the intention of the requirement is that WHEN/AFTER the decision is made to invoke mobility support, then the mobility support is transparent to the application. Then we may want to check and make sure the emphasis of this requirement does mean transparency in this respect only. 

Original wording:

   REQ2:  Transparency to Upper Layers when needed
 
          DMM solutions MUST provide transparent mobility support above
          the IP layer when needed.  Such transparency is needed, for
          example, when, upon change of point of attachment to the
          network, an application flow cannot cope with a change in the
          IP address.  However, it is not always necessary to maintain a
          stable home IP address or prefix for every application or at
          all times for a mobile node.

I now tend to think the first sentence in this original wording may steer the emphasis on providing transparent support, which is not what the motivation and the problems are talking about. The motivation and the problems are talking about when they are not needed. The emphasis of this requirement therefore is on the capability to turn OFF unnecessary mobility support. 

How about the following

   REQ2:  Network-layer mobility support ONLY when needed
 
          DMM solutions MUST NOT provide network-layer mobility support
          when NOT needed.

(or if you don't like double negatives:
          (DMM solutions MUST provide network-layer 
          mobility support ONLY when needed)

          Such transparent mobility support above the IP layer is needed, for

Any comments/changes/corrections?

H Anthony Chan

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Tuesday, January 28, 2014 8:43 AM
To: [email-masked]
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

> - I am a little confused by REQ2.  It says that a DMM solution should be transparent to the applications.

This remark is typically true when we talk Mobile IP on a Mobile Host and an application like firefox runs above a BSD Socket interface.

Transparency?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Jan 2014 20:27:00 +0100

> providing IP mobility by default.

First, providing mobility by default is not a black/white alternative to
not providing mobility.

It is very possible on the same machine to have Mobile IP enabled for
some flows and disabled for others (depending what we call a 'flow'). 
It is also possible to have Mobile IP and NAT at the same time on the 
same Mobile Router.

> Without this requirement, mobility support may be provided by
> default, which is transparent to higher layers.

Again, transparency to higher layers means we talk mobility management
on a Mobile Host.

Transparency to higher layers has little meaning if we talk mobility
management provided on a Mobile Router (which is not a Mobile Host).

> With this requirement, assume there are separate steps in the DMM
> solution. 1. A decision is made whether network-layer mobility
> support is needed. 2. When the need is established, network-layer
> mobility support is invoked. 3. Then transparent support is provided
>  and is transparent to layers above IP.
>

This looks like a trigger which enables mobility, or other times
disables it.

But one can have a Mobile IP daemon and a NAT run at the same time on
the same machine.  There is no decision in time.

Some decision happens at packet based on IP destination address.

> The question however is whether the preceding steps involve the
> application, so that one may question whether the entire DMM solution
> (with all the steps) as a whole is transparent.

I agree.  I am not aware of any application which talks to Mobile IP. 
Whenever it is there it is 'transparent'.

> So the intention of the requirement is that WHEN/AFTER the decision
> is made to invoke mobility support, then the mobility support is
> transparent to the application. Then we may want to check and make
> sure the emphasis of this requirement does mean transparency in this
>  respect only.

I disagree.

As I said above, the word 'transparency' is dubious.  Some times it may 
mean 'non-existent', some times it may mean light goes through it but 
modified.

If one wants to continue using it, then one should better qualify it
with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'.

Because a Mobile Router doing mobility management in a transparent
manner on the Mobile Router for the LFN has nothing to do with
applications, neither with upper layers.

Also, a Mobile Router doing NAT and Mobile IP at the same time is
50%-transparent.

> DMM solutions MUST provide transparent mobility support above the IP
>  layer when needed.  Such transparency is needed, for example, when,
                    ^on a Mobile Host.
> upon change of point of attachment to the network, an application
> flow cannot cope with a change in the IP address.

(it's not the application flow, it is a socket which some times may
break [paste here the error from the screen]; the term 'application 
flow' in this context has little meaning)

(an 'application flow' has no understandable meaning in practice).

> However, it is not always necessary to maintain a stable home IP
> address or prefix for every application or at all times for a mobile
> node.
       ^a Mobile Host.

I agree.

> I now tend to think the first sentence in this original wording may
> steer the emphasis on providing transparent support, which is not
> what the motivation and the problems are talking about.

I agree.

> The motivation and the problems are talking about when they are not
> needed. The emphasis of this requirement therefore is on the
> capability to turn OFF unnecessary mobility support.

In a sense I agree with the meaning.

But when trying to turn off or on mobility support the things are not 
like if there were a knob on/off, not even like starting/stopping some 
daemon.  It is a matter of always having the Mobile IP support on, and 
tweak the routing table with some particular entries, and the 
firewalling rules to NAT some addresses or not.

> REQ2:  Network-layer mobility support ONLY when needed

If we understood better when it was needed...

> DMM solutions MUST NOT provide network-layer mobility support when
> NOT needed.

I would say that Mobile IP MUST always be turned on on a Mobile Host.

> (or if you don't like double negatives: (DMM solutions MUST provide
> network-layer mobility support ONLY when needed)

No, I would say to have it always on.  If some applications don't want 
it then dont use it; realize that by inserting routing table entries.

One may wonder when some applications dont want it.  One answer is when 
some applications prefer to not go through the HA in order to take 
advantage of the 4G pure speed.  When? For example if the HA link is too 
slow compared to 4G.  (remark this is not the same as saying that the 
triangular route is longer than straight, because that is always true).

This is not a request for Route Optimization.  It is an invitation to 
analyze in deeper detail the application needs.

One may have an application start via the HA (offer reachability) and 
continue straight, w/o HA.  It's the same application.

Consider a video-call like appli: you want to be reachable always at the 
same IP address (through HA) but once the session is ongoing you may not 
want to use it through HA if no handover in sight.

Something like that.

These things could be further refined if we really went into detail and 
understood what are the needs of applications, the distinctions MH-MR, etc.

> example, when, upon change of point of attachment to the network, an
>  application flow cannot cope with a change in the IP address.
> However, it is not always necessary to maintain a stable home IP
> address or prefix for every application or at all times for a mobile
>  node.

A Mobile Host never maintains a stable prefix, only a stable address.

A Mobile Router may maintain a stable address (its HoA) and may maintain 
a stable prefix  (its MNP).  It could also just maintain stable just its 
MNP, but not its HoA; and vice-versa.  Is that mobility?

For each of these there is an application :-)

Alex

> -----Original Message----- From: dmm [mailto:[email-masked]] On
> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 AM
> To: [email-masked] Subject: Re: [DMM] AD Evaluation:
> draft-ietf-dmm-requirements
>
>> 5. Section 5: - I am a little confused by REQ2.  It says that a DMM
>> solution should be transparent to the applications.
>
>> However, the motivation talks about identifying applications that
>> do (or do not) need mobility support from the network layer.  That
>>  doesn't sound transparent to me.  Am I reading this incorrectly?
>>
>> It appears that unless the network can find out whether the
>> application has need of such support, the application indeed may
>> need to invoke mobility support or has to convey its need to the
>> network.
>>
>> The emphasis of requirement is on "when needed." So, I think it is
>>  better to drop the word "transparent" as follows:
>>
>> DMM solutions MUST provide mobility support to above the IP layer
>> when needed.  Such support is needed, for example, when, upon
>> change of point of attachment to the network, an application flow
>> cannot cope with a change in the IP address.  However, it is not
>> always necessary to maintain a stable home IP address or prefix for
>> every application or at all times for a mobile node.
>>
>> Motivation: The motivation of this requirement is to enable more
>> efficient routing and more efficient use of network resources by
>> selecting an IP address or prefix according to whether mobility
>> support is needed and by not maintaining context at the mobility
>> anchor when there is no such need.
>
> Whenever we discuss this 'transparency' paragraph I have again the
> same comments.
>
> If the applications run on the LFN, the change of the attachment of
> the MR is 'transparent' to them, regardless whether or not MR does
> something to maintain stability of that address (Mobile IP, other).
>
> Second, this transparency may depend on the direction, or more
> complex 'shape' of the application flows.  Some IP flows of some
> applications have very complex 'shapes', with various sets of IP src
>  and dst, and triangular or HA-less shapes.
>
> intermediary and behind NAT is followed by the ongoing 4 flows (2
> audio 2 video)... they all take different paths... each may need or
> not need to go through the HA, and each has distinct behaviours when
>  the IP address changes, hence each would have a distinct
> 'transparency' requirement.  Is this _one_ application?
>
> Alex
>
>>
>> H Anthony Chan
>>
>> -----Original Message----- From: dmm [mailto:[email-masked]]
>>  On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20
>> AM To: h chan; [email-masked];
>> [email-masked]; Peter McCann Subject: Re: [DMM] AD Evaluation:
>> draft-ietf-dmm-requirements
>>
>>
>>
>>> 4. Section 4: - I am not sure that it benefits the document to
>>> label PS6 and PS7 as related.  Those issues are problematic on
>>> their own. If you remove the "(related problem)" label from them,
>>> make sure that REQ2 is updated to remove mention of "related
>>> problem".
>>>
>>> The intention of the name "related problems" was not to suggest
>>> they are less problematic, but rather to distinguish them from
>>> the other problems directly on mobility management. Although
>>> these problems are not directly on mobility management, the DMM
>>> solutions can solve these additional problems. They are therefore
>>> included. So, as long as this section is not to be interpreted as
>>> limited to problems directly on mobility management, we can drop
>>> the word "related."
>>>
>>
>> Regards, Brian
>> _______________________________________________ dmm mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>>
>>
>
>
> _______________________________________________ dmm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>
>

---

From: h chan <[email-masked]>
Date: Tue, 28 Jan 2014 20:31:27 +0000

REQ6:  Security considerations

          A DMM solution MUST NOT introduce new security risks or

          amplify existing security risks against which the existing

          security mechanisms/protocols cannot offer sufficient

          protection.

The intention of REQ6 is NOT that it cannot introduce new vulnerabilities at all.

Rather the protection against such new vulnerablities can be limited to the use of existing security protocols. It is okay to provide additional means to protect against new risks as long as they do not require development of new security protocols which are needed for DMM alone but are not needed otherwise. Else a network deploying DMM versus a network not deploying DMM will need additional security protocols which are not needed otherwise.

So I think the word: "existing" security mechanisms/protocols is intended to exclude protocols that are not needed otherwise.

We can clarify with the following:

   REQ6:  Security considerations

          A DMM solution MUST NOT introduce new security risks or

          amplify existing security risks against which security means using existing

          security mechanisms/protocols CANNOT offer sufficient

          protection.

H Anthony Chan

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Friday, January 24, 2014 11:30 AM
To: [email-masked]; [email-masked]; Peter McCann
Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements

All,

2. Introduction:

3. Section 3:

4. Section 4:

5. Section 5:

Regards,

Brian

---

From: h chan <[email-masked]>
Date: Tue, 28 Jan 2014 21:33:54 +0000

Regarding the following:

I think the bottom line is that the existing ones do not break.

Original

   REQ5:  Co-existence with deployed networks and hosts

          The DMM solution MUST be able to co-exist with existing

          network deployments and end hosts.  For example, depending on

          the environment in which DMM is deployed, DMM solutions may

          need to be compatible with other deployed mobility protocols

          or may need to co-exist with a network or mobile hosts/routers

          that do not support DMM protocols.  The mobile node may also

          move between different access networks, where some of them may

          support neither DMM nor another mobility protocol.

          Furthermore, a DMM solution SHOULD work across different

          networks, possibly operated as separate administrative

          domains, when allowed by the trust relationship between them.

We can change to:

   REQ5:  Co-existence with deployed networks and hosts

          The DMM solution MUST be able to co-exist with existing

          network deployments and end hosts without breaking them.  For example, depending on

          the environment in which DMM is deployed, DMM solutions may

          need to be compatible with other deployed mobility protocols

          or may need to co-exist with a network or mobile hosts/routers

          that do not support DMM protocols.  The mobile node may also

          move between different access networks, where some of them may

          support neither DMM nor another mobility protocol.

          Furthermore, a DMM solution SHOULD work across different

          networks, possibly operated as separate administrative

          domains, when allowed by the trust relationship between them.

H Anthony Chan

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Friday, January 24, 2014 11:30 AM
To: [email-masked]; [email-masked]; Peter McCann
Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements

All,

2. Introduction:

3. Section 3:

4. Section 4:

5. Section 5:

Regards,

Brian

---

From: h chan <[email-masked]>
Date: Tue, 28 Jan 2014 21:58:38 +0000

Regarding the following:

Original

   PS7:  Deployment with multiple mobility solutions

         There are already many variants and extensions of MIP.

         Deployment of new mobility management solutions can be

         challenging, and debugging difficult, when they co-exist with

         solutions already deployed in the field.

We can change to

   PS7:  Deployment with multiple mobility solutions

         There are already many variants and extensions of MIP

         as well mobility solutions at other layers.

         Deployment of new mobility management solutions can be

         challenging, and debugging difficult, when they co-exist with

         solutions already deployed in the field.

H Anthony Chan

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Friday, January 24, 2014 11:30 AM
To: [email-masked]; [email-masked]; Peter McCann
Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements

All,

2. Introduction:

3. Section 3:

4. Section 4:

5. Section 5:

Regards,

Brian

---

From: h chan <[email-masked]>
Date: Tue, 28 Jan 2014 22:33:28 +0000

Let us try to include MR.  

How about the following

   REQ2:  Network-layer mobility support when needed
 
          DMM solutions MUST enable network-layer 
          mobility when needed.
          Such mobility support is needed, for
          example, when an application or a host cannot cope with a change in the
          IP address when a node moves.  However, it is not always necessary to maintain a
          stable IP address or prefix.

Here, the node can be a mobile host or a mobile router. 
A host can be a mobile host or a host in a LFN. 
An application can be running on a mobile host or a on a host in a LFN.
A MR also does not need to maintain stable IP address or prefix when there are no hosts attached to it or when there are no active applications running in the hosts of its network. 

H Anthony Chan

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2014 1:27 PM
To: h chan; [email-masked]
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

> providing IP mobility by default.

First, providing mobility by default is not a black/white alternative to not providing mobility.

It is very possible on the same machine to have Mobile IP enabled for some flows and disabled for others (depending what we call a 'flow'). 
It is also possible to have Mobile IP and NAT at the same time on the same Mobile Router.

> which is transparent to higher layers.

Again, transparency to higher layers means we talk mobility management on a Mobile Host.

Transparency to higher layers has little meaning if we talk mobility management provided on a Mobile Router (which is not a Mobile Host).

> solution. 1. A decision is made whether network-layer mobility support 
> is needed. 2. When the need is established, network-layer mobility 
> support is invoked. 3. Then transparent support is provided  and is 
> transparent to layers above IP.
>

This looks like a trigger which enables mobility, or other times disables it.

But one can have a Mobile IP daemon and a NAT run at the same time on the same machine.  There is no decision in time.

> So the intention of the requirement is that WHEN/AFTER the decision is 
> made to invoke mobility support, then the mobility support is 

I disagree.

As I said above, the word 'transparency' is dubious.  Some times it may mean 'non-existent', some times it may mean light goes through it but modified.

If one wants to continue using it, then one should better qualify it with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'.

Because a Mobile Router doing mobility management in a transparent manner on the Mobile Router for the LFN has nothing to do with applications, neither with upper layers.

Also, a Mobile Router doing NAT and Mobile IP at the same time is 50%-transparent.

                    ^on a Mobile Host.
> upon change of point of attachment to the network, an application flow 
> cannot cope with a change in the IP address.

(it's not the application flow, it is a socket which some times may break [paste here the error from the screen]; the term 'application flow' in this context has little meaning)

       ^a Mobile Host.

I agree.

> steer the emphasis on providing transparent support, which is not what 
> the motivation and the problems are talking about.

I agree.

But when trying to turn off or on mobility support the things are not like if there were a knob on/off, not even like starting/stopping some daemon.  It is a matter of always having the Mobile IP support on, and tweak the routing table with some particular entries, and the firewalling rules to NAT some addresses or not.

> DMM solutions MUST NOT provide network-layer mobility support when NOT 
> needed.

> network-layer mobility support ONLY when needed)

No, I would say to have it always on.  If some applications don't want it then dont use it; realize that by inserting routing table entries.

One may wonder when some applications dont want it.  One answer is when some applications prefer to not go through the HA in order to take advantage of the 4G pure speed.  When? For example if the HA link is too slow compared to 4G.  (remark this is not the same as saying that the triangular route is longer than straight, because that is always true).

This is not a request for Route Optimization.  It is an invitation to analyze in deeper detail the application needs.

One may have an application start via the HA (offer reachability) and continue straight, w/o HA.  It's the same application.

Consider a video-call like appli: you want to be reachable always at the same IP address (through HA) but once the session is ongoing you may not want to use it through HA if no handover in sight.

Something like that.

These things could be further refined if we really went into detail and understood what are the needs of applications, the distinctions MH-MR, etc.

A Mobile Router may maintain a stable address (its HoA) and may maintain a stable prefix  (its MNP).  It could also just maintain stable just its MNP, but not its HoA; and vice-versa.  Is that mobility?

Alex

>> However, the motivation talks about identifying applications that do 
>> (or do not) need mobility support from the network layer.  That  
>> application has need of such support, the application indeed may need 
>> to invoke mobility support or has to convey its need to the network.
>>
>> when needed.  Such support is needed, for example, when, upon change 
>> of point of attachment to the network, an application flow cannot 
>> cope with a change in the IP address.  However, it is not always 
>> necessary to maintain a stable home IP address or prefix for every 
>> application or at all times for a mobile node.
>>
>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 AM 
>> To: h chan; [email-masked];
>>> If you remove the "(related problem)" label from them, make sure 
>>> that REQ2 is updated to remove mention of "related problem".
>>>
>>> problems directly on mobility management. Although these problems 
>>> are not directly on mobility management, the DMM solutions can solve

---

From: Brian Haberman <[email-masked]>
Date: Wed, 29 Jan 2014 08:56:40 -0500

>           security mechanisms/protocols CANNOT offer sufficient

The above seems a little clunky.  Does this work for everyone?

A DMM solution MUST NOT introduce new security risks, or amplify
existing security risks, that cannot be mitigated by existing security
mechanisms or protocols.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 29 Jan 2014 09:01:10 -0500

>           domains, when allowed by the trust relationship between them.

The "without breaking" is fine.  However, the "need to be compatible
with" phrasing is still problematic.  Is that inferring that in some
situations that a DMM solution would need to interact with, for example,
PMIP?

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 29 Jan 2014 09:01:48 -0500

That works for me.

Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 29 Jan 2014 09:26:02 -0500

Anthony,
     Does this requirement also include a way for the application (or
transport protocol) to request/refuse mobility support?  The "when
needed" implies some type of knowledge that is either manually
configured or signaled from the upper layer.

Regards,
Brian

---

From: Hassan ALI AHMAD <[email-masked]>
Date: Wed, 29 Jan 2014 18:17:41 +0100

Hello,

I think that SIP is a good example to clarify the idea. SIP can support
mobility for SIP-based sessions at the application layer. The sessions that
are initiated by SIP signaling (the INVITE procedure) can refuse IP
mobility support at the network layer (if the operator prefers this choice
and configures it). Then, mobility will be handled by SIP signaling
(re-INVITE) at the application layer.

Some people may not agree to apply this, but it's still a simple and valid
example.

Best regards,
Hassan

On Wed, Jan 29, 2014 at 3:26 PM, Brian Haberman <[email-masked]>wrote:

> > A MR also does not need to maintain stable IP address or prefix when
> there are no hosts attached to it or when there are no active applications
> running in the hosts of its network.
> >
> break [paste here the error from the screen]; the term 'application flow'
> in this context has little meaning)
> >
> tweak the routing table with some particular entries, and the firewalling
> rules to NAT some addresses or not.
> >
> >> How about the following
> >>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Jan 2014 19:30:04 +0100

> Here, the node can be a mobile host or a mobile router.

I am not sure the term 'node' is agreed to cover both an MH and an MR.

I think in all descriptions it would be clearer if we just said MH when 
we meant Mobile Host and MR when we meant Mobile Router.

Le me paraphrase this text in RFC6275:

>    This document specifies a protocol that allows nodes to remain
>    reachable while moving around in the IPv6 Internet.  Without specific
>    support for mobility in IPv6 [6], packets destined to a mobile node
>    would not be able to reach it while the mobile node is away from its
>    home link.

There is a clear ambiguity in the 'mobile node' used above.  Because if 
we talk moving networks then often the packets are destined (the 
contents of the destination address) to a LFN, not to the MR.

If that 'node' were a Mobile Router (not a Mobile Host) it completely 
misses the case when packets are destined to the LFN, which is not an MH 
nor an MR.

The phrase should rather say:

'packets destined to a MH (or to a LFN behind a MR) would not be able
  to reach it while that MH (or the MR and LFN) is away from its home
  link.'

This kind if expression would be clearer.

Alex

'packets destined to a [LFN] or to the Mobile Host, or to the Mobile 
Router, would not be able to reach it while the Mobile Router is away 
from its home link'.

---

From: h chan <[email-masked]>
Date: Wed, 29 Jan 2014 18:51:46 +0000

Brian,

The requirement is intended to include a capability of not using network-layer mobility management, as opposed to using it by default.  

I think it is sufficient to leave to the explanation (the sentences after the first sentence) to say that network-layer mobility support is not always needed in order to justify this capability. 

The alternative then is to say that network-layer mobility is provided but it is possible to not use such support. 

    REQ2:  Using and not Using Network-layer mobility support
  
           DMM solutions MUST enable network-layer mobility
           but it MUST be possible to not invoke it.
           Mobility support is needed, for example, 
           when an application or a host 
           cannot cope with a change in the
           IP address when a node moves.  
           Yet a mobile node can often be stationary,
           and mobility support can also be provided at other layers.
           It is then not always necessary to maintain a
           stable IP address or prefix.

Of cause "enable" does not mean it must be used. Yet explicitly say "it is possible to not invoke it" is to draw the contrast to using it by default.

H Anthony Chan

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Wednesday, January 29, 2014 8:26 AM
To: h chan; Alexandru Petrescu; [email-masked]
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

Anthony,
     Does this requirement also include a way for the application (or transport protocol) to request/refuse mobility support?  The "when needed" implies some type of knowledge that is either manually configured or signaled from the upper layer.

Regards,
Brian

On 1/28/14 5:33 PM, h chan wrote:
>>> need to invoke mobility support or has to convey its need to the network.
>>>
>>>> label
>>>> they are less problematic, but rather to distinguish them from the 
>>>> other problems directly on mobility management. Although these 
>>>> problems are not directly on mobility management, the DMM solutions 
>>>> can solve these additional problems. They are therefore included. 
>>>> So, as long as this section is not to be interpreted as limited to 
>>>> problems directly on mobility management, we can drop the word "related."
>>>>
>>>

---

From: h chan <[email-masked]>
Date: Wed, 29 Jan 2014 18:53:58 +0000

Delete those explanatory sentences then.

          network deployments and end hosts.  

H Anthony Chan

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Wednesday, January 29, 2014 8:01 AM
To: h chan; [email-masked]; [email-masked]; Peter McCann
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

>           domains, when allowed by the trust relationship between them.

The "without breaking" is fine.  However, the "need to be compatible with" phrasing is still problematic.  Is that inferring that in some situations that a DMM solution would need to interact with, for example, PMIP?

Regards,
Brian

---

From: h chan <[email-masked]>
Date: Wed, 29 Jan 2014 19:45:27 +0000

Alex

How about the following:

           when an application (of a MN or a host in a mobile network of a MR)

           IP address of the mobile node when the node moves.

Can the text in red be valid for both host or router?

When the node is a router:

an application (of a host in a mobile network) may not be able to cope with a change in the IP address of the MR when the MR moves.

When the node is a host

an application (of a MN) may not be able to cope with a change in the IP address of the MN when the MN moves.

H Anthony Chan

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]]
Sent: Wednesday, January 29, 2014 12:30 PM
To: h chan; [email-masked]
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

I think in all descriptions it would be clearer if we just said MH when we meant Mobile Host and MR when we meant Mobile Router.

>    home link.

There is a clear ambiguity in the 'mobile node' used above.  Because if we talk moving networks then often the packets are destined (the contents of the destination address) to a LFN, not to the MR.

If that 'node' were a Mobile Router (not a Mobile Host) it completely misses the case when packets are destined to the LFN, which is not an MH nor an MR.

  link.'

Alex

'packets destined to a [LFN] or to the Mobile Host, or to the Mobile Router, would not be able to reach it while the Mobile Router is away from its home link'.

> To: h chan; [email-masked]<mailto:[email-masked]>

>> What is new in this requirement is "when needed" in contrast to

>> providing IP mobility by default.

>> To: [email-masked]<mailto:[email-masked]> Subject: Re: [DMM] AD Evaluation:

>>> To: h chan; [email-masked]<mailto:[email-masked]>;

>>> [email-masked]<mailto:[email-masked]>; Peter McCann Subject: Re: [DMM] AD Evaluation:

>>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/dmm

>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/dmm

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 Jan 2014 09:13:20 +0100

> when an application (of a MN or a host in a mobile network of a MR)
                                   ^a LFN
(because just 'host' may be confused with Mobile Host; and also because 
within the moving network there is also one or several Routers - not hosts.)

> IP address of the mobile node when the node moves.
                    ^Mobile Host or of the Mobile Router moves
(because when the 'node' moves it may mean that the 'host' in the moving 
network moves, and that doesn't change its IP address).

> Can the text in red be valid for both host or router?

Yes and no.  I agree with it, but I'd prefer the suggested modifications.

Alex

> an application (of a host in a mobile network) may not be able to
> cope with a change in the IP address of the MR when the MR moves.
>
> When the node is a host
>
> -----Original Message----- From: Alexandru Petrescu
> [mailto:[email-masked]] Sent: Wednesday, January 29,
> 2014 12:30 PM To: h chan; [email-masked] Subject: Re: [DMM] AD
> Evaluation: draft-ietf-dmm-requirements
>
> I think in all descriptions it would be clearer if we just said MH
> when we meant Mobile Host and MR when we meant Mobile Router.
>
> There is a clear ambiguity in the 'mobile node' used above.  Because
> if we talk moving networks then often the packets are destined (the
>  misses the case when packets are destined to the LFN, which is not
> an MH nor an MR.
>
>  Router, would not be able to reach it while the Mobile Router is
> away from its home link'.
>
> there are no hosts attached to it or when there are no active
> applications running in the hosts of its network.
>
>>
>
>> To: h chan; [email-masked] <mailto:[email-masked]>
>
>> First, providing mobility by default is not a black/white
>> alternative
> to not providing mobility.
>
>>
>
>> As I said above, the word 'transparency' is dubious.  Some times it
>>
> may mean 'non-existent', some times it may mean light goes through it
>  but modified.
>
>>
>
> like if there were a knob on/off, not even like starting/stopping
> some daemon.  It is a matter of always having the Mobile IP support
> on, and tweak the routing table with some particular entries, and the
>>> when
>> No, I would say to have it always on.  If some applications don't
> want it then dont use it; realize that by inserting routing table
> entries.
>
>>
>
>> One may wonder when some applications dont want it.  One answer is
>>
> when some applications prefer to not go through the HA in order to
> take advantage of the 4G pure speed.  When? For example if the HA
> link is too slow compared to 4G. (remark this is not the same as
> saying that the triangular route is longer than straight, because
> that is always true).
>
>>
>
>> Consider a video-call like appli: you want to be reachable always
>> at
> the same IP address (through HA) but once the session is ongoing you
> may not want to use it through HA if no handover in sight.
>
>>
>
>> Something like that.
>
>>
>
>> These things could be further refined if we really went into detail
>>
> and understood what are the needs of applications, the distinctions
> MH-MR, etc.
>
>>
>
>> A Mobile Router may maintain a stable address (its HoA) and may
> maintain a stable prefix  (its MNP).  It could also just maintain
> stable just its MNP, but not its HoA; and vice-versa.  Is that
> mobility?
>
>>
>
>>> To: [email-masked] <mailto:[email-masked]> Subject: Re: [DMM] AD
>>> Evaluation:
>
>>>> change
>>>> more
>>>> AM
>>>> To: h chan; [email-masked]
> <mailto:[email-masked]>;
>
>>>> [email-masked] <mailto:[email-masked]>; Peter McCann Subject: Re:
>>>> [DMM]
> AD Evaluation:
>
>>>>> problems directly on mobility management, we can drop the
>>>>> word
> "related."
>
>>>>>
>
>>>>
>
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: Brian Haberman <[email-masked]>
Date: Thu, 30 Jan 2014 09:01:38 -0500

Hi Anthony,

On 1/29/14 1:51 PM, h chan wrote:
> Brian,
> 
> The requirement is intended to include a capability of not using
> network-layer mobility management, as opposed to using it by default.
> 
> 
> I think it is sufficient to leave to the explanation (the sentences
> after the first sentence) to say that network-layer mobility support
> is not always needed in order to justify this capability.
> 
> The alternative then is to say that network-layer mobility is
> provided but it is possible to not use such support.
> 
> DMM solutions MUST enable network-layer mobility but it MUST be
> possible to not invoke it. Mobility support is needed, for example, 
> when an application or a host cannot cope with a change in the IP
> address when a node moves. Yet a mobile node can often be
> stationary, and mobility support can also be provided at other
> layers. It is then not always necessary to maintain a stable IP
> address or prefix.
> 
> Of cause "enable" does not mean it must be used. Yet explicitly say
> "it is possible to not invoke it" is to draw the contrast to using it
> by default.

My only concern is that it is unclear *who* invokes the network-layer
mobility support.  Is it envisioned that the application can signal the
need for mobility support?  Does the user have to configure which
applications get support?

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 30 Jan 2014 09:03:03 -0500

Anthony,
     I am fine with that.  I would like feedback from the rest of the WG
on these changes.

Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 Jan 2014 15:18:08 +0100

>>            domains, when allowed by the trust relationship between them.

I agree with this formulation of this requirement.

If I take a route update mechanism (such as based on BGP), I think it 
could fulfill that requirement.

Many network deployments involve BGP, so this would be compatible.

When inter-connecting domains in a secure manner, BGP would also work.

The problem would be, of course, not to disturb it too much, if I can 
say so.  I suppose there is a requirement for this as well.

Alex

---

From: h chan <[email-masked]>
Date: Thu, 30 Jan 2014 17:08:33 +0000

Alex,

Is the following correct?

           Mobility support is needed, for example, 
           when a mobile host or a mobile router moves 
           and an application in the mobile host or 
           in a host that moves with the router 
           cannot cope with a change
           in the IP address of the mobile node.

H Anthony Chan

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Thursday, January 30, 2014 2:13 AM
To: h chan; [email-masked]
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

> when an application (of a MN or a host in a mobile network of a MR)
                                   ^a LFN (because just 'host' may be confused with Mobile Host; and also because within the moving network there is also one or several Routers - not hosts.)

> IP address of the mobile node when the node moves.
                    ^Mobile Host or of the Mobile Router moves (because when the 'node' moves it may mean that the 'host' in the moving network moves, and that doesn't change its IP address).

Alex

> an application (of a host in a mobile network) may not be able to cope 
> with a change in the IP address of the MR when the MR moves.
>
> When the node is a host
>
> misses the case when packets are destined to the LFN, which is not an 
> MH nor an MR.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 Jan 2014 18:39:14 +0100

Le 30/01/2014 18:08, h chan a écrit :
> Mobility support is needed, for example, when a mobile host or a
> mobile router moves and an application in the mobile host or in a
> host that moves with the router cannot cope with a change in the IP
> address of the mobile node.

Makes better sense, thanks.

But still uses that word 'Mobile Node' which is confusing.  How about this:

> Mobility support is needed, for example, when a Mobile Host or a
> Mobile Router moves and an application in the Mobile Host or in a
> host or router that moves with that Mobile Router cannot cope with a
> change in the IP address of the mobile host or of that Mobile
> Router.

It would be more precise.

But even then, it does not hold, because a Host that moves with the
Mobile Router is not that much influenced by the change of IP address of
that MR.  When the MR changes its IP address, the Host feels it just
like some other interruption in the path to another CN.  These kinds of
interruptions (link up/down) happen often in the fixed networks and yet
Hosts continue to work.

It is possible, for example, to have a Mobile Router move, have NAT (not
mobility management), change IP address, and the Hosts and Routers in
that moving network will continue working ok.

It is also possible for MR to not have NAT, and forward packets with an
address which is not topological correct in that network.  These packets
will reach their destinations (provided there's no ingress filtering),
and the replies will not arrive.  Some applications do not need packets
to return.  One can very well have a vehicle which streams the video of
its front camera to some particular server in the Internet, and change
its IP address at each access.  This does not require Mobile IP nor NAT.

I think it is impossible to stay meaningful in one phrase talking both
Mobile Host and Mobile Router at the same time.  I think we need maybe
two phrases.

> Mobility Support on a Mobile Host is needed, for example, when a
> Mobile Host moves and an arbitrary application in the Mobile Host
> cannot cope with a change in the IP address of that Mobile Host
> [paste socket error message here].
>
> Mobility Support on a Mobile Router is needed, for example, when a
> Mobile Router moves together with a set of Hosts and Routers, and
> arbitrary applications in the Hosts and Routers need to maintain
> their IP address fixed regardless of the change of the IP address of
> the Mobile Router, and the Access Router performs ingress filtering,
> and reachability of these Hosts and Routers at a fixed IP address is
>  necessary.

Alex

> [mailto:[email-masked]] Sent: Thursday, January 30,
> 2014 2:13 AM To: h chan; [email-masked] Subject: Re: [DMM] AD
> ^a LFN (because just 'host' may be confused with Mobile Host; and
> also because within the moving network there is also one or several
> Routers - not hosts.)
>
> ^Mobile Host or of the Mobile Router moves (because when the 'node'
> moves it may mean that the 'host' in the moving network moves, and
> that doesn't change its IP address).
>
>> an application (of a MN) may not be able to cope with a change in
>> the IP address of the MN when the MN moves.
>>
>> H Anthony Chan
>>
>> If that 'node' were a Mobile Router (not a Mobile Host) it
>> completely misses the case when packets are destined to the LFN,
>> which is not an MH nor an MR.
>>
>> 'packets destined to a [LFN] or to the Mobile Host, or to the
>> Mobile Router, would not be able to reach it while the Mobile
>> Router is away from its home link'.
>>
>> may mean 'non-existent', some times it may mean light goes through
>> it but modified.
>>
>>>
>>
>>>> the IP
>> some daemon.  It is a matter of always having the Mobile IP
>> support on, and tweak the routing table with some particular
>> entries, and the firewalling rules to NAT some addresses or not.
>>
>>>
>>
>>>> How about the following
>>
>>>>
>>
>> the same IP address (through HA) but once the session is ongoing
>> you may not want to use it through HA if no handover in sight.
>>
>>>
>>
>>> Something like that.
>>
>>>
>>
>>>> network, an

---

From: h chan <[email-masked]>
Date: Thu, 30 Jan 2014 18:46:18 +0000

The reason for this requirement is that in some existing mobility management deployment, in order to support those applications that does need network-layer mobility support, the mobile host uses HoA so that all the applications must use the HoA. Then it does not make it possible for an application to not use HoA.  

So the bottom line in this revision is that the DMM solution only allows the possibility of not using the network-layer mobility support. 

How to make use of this possibility is now not a part of this requirement. Therefore the requirement should avoid implication of such mechanisms.

When we called "when needed", there may be implication of a mechanism to determine/convey the need.

When we call it "invoke", there may be implication of a mechanism to invoke.

Let me try the following:

    REQ2:  Bypassable Network-layer mobility support
  
           DMM solutions MUST enable network-layer mobility
           but it MUST be possible to bypass it.

           (plus other sentences on the need and the no need to serve as explanations only to justify the above)

H Anthony Chan

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Thursday, January 30, 2014 8:02 AM
To: h chan; [email-masked]
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

Hi Anthony,

On 1/29/14 1:51 PM, h chan wrote:
> The alternative then is to say that network-layer mobility is provided 
> but it is possible to not use such support.
> 
> address when a node moves. Yet a mobile node can often be stationary, 
> and mobility support can also be provided at other layers. It is then 
> not always necessary to maintain a stable IP address or prefix.
> 

My only concern is that it is unclear *who* invokes the network-layer mobility support.  Is it envisioned that the application can signal the need for mobility support?  Does the user have to configure which applications get support?

Regards,
Brian

---

From: h chan <[email-masked]>
Date: Thu, 30 Jan 2014 19:53:14 +0000

Alex,

I think the applications which work without MIP are the applications that can cope with the change of IP address of the MR. Is that correct? Then mobility support is needed only for those applications that cannot cope with the change of IP address of the MR.

So, in the two separate sentences:

> cannot cope with a change in the IP address of that Mobile Host [paste 
> socket error message here].

Is this MN sentence the same as:
           Mobility support is needed, for example, 
           when a mobile host moves and an application 
           cannot cope with a change in the IP address of the mobile host.

> arbitrary applications in the Hosts and Routers need to maintain their 
> IP address fixed regardless of the change of the IP address of the 
> Mobile Router, and the Access Router performs ingress filtering, and 
> reachability of these Hosts and Routers at a fixed IP address is  
> necessary.

When the MR carries a network of hosts and routers, doesn't these routers in turn carry network so that at the final level of hosts, the applications are running there. If so, is it sufficient to state the applications in the hosts? (which includes hosts in the network of routers which are in turn in the network of the mobile router)
So a host in the network of a router, which in turn is in the network of another router, which .... in the network of the mobile router can be called a host that moves with the mobile router. 

Then is the MR sentence the above the same as

           Mobility support is also needed, for example, 
           when a mobile router moves together
           and an application in a host that moves with the mobile router 
           cannot cope with a change of IP address of the mobile router.

           DMM solutions MUST enable network-layer mobility
           but it MUST be possible to not use it.

           Mobility support is needed, for example, 
           when a mobile host moves and an application 
           cannot cope with a change in the IP address.

           Mobility support is also needed, for example, 
           when a mobile router moves together
           and an application in a host which moves with the mobile router 
           cannot cope with a change of IP address of the mobile router.

           However mobility support at the network-layer is not always needed;
           a mobile node can often be stationary,
           and mobility support can also be provided at other layers.
           It is then not always necessary to maintain a
           stable IP address or prefix.

One more alternative is to mention the "no need" case only without explaining the "needed" case as in the following. Yet if it is possible to state the "needed" case more concisely, it will be more clear to spell that out as in above. 

           DMM solutions MUST enable network-layer mobility
           but it MUST be possible to not use it.
           Mobility support at the network-layer is not always needed;
           a mobile node can often be stationary,
           and mobility support can also be provided at other layers.
           It is then not always necessary to maintain a
           stable IP address or prefix.

H Anthony Chan

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Thursday, January 30, 2014 11:39 AM
To: h chan; [email-masked]
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

Le 30/01/2014 18:08, h chan a écrit :
> mobile router moves and an application in the mobile host or in a host 
> that moves with the router cannot cope with a change in the IP address 
> of the mobile node.

But still uses that word 'Mobile Node' which is confusing.  How about this:

> Mobile Router moves and an application in the Mobile Host or in a host 
> or router that moves with that Mobile Router cannot cope with a change 
> in the IP address of the mobile host or of that Mobile Router.

But even then, it does not hold, because a Host that moves with the Mobile Router is not that much influenced by the change of IP address of that MR.  When the MR changes its IP address, the Host feels it just like some other interruption in the path to another CN.  These kinds of interruptions (link up/down) happen often in the fixed networks and yet Hosts continue to work.

It is possible, for example, to have a Mobile Router move, have NAT (not mobility management), change IP address, and the Hosts and Routers in that moving network will continue working ok.

It is also possible for MR to not have NAT, and forward packets with an address which is not topological correct in that network.  These packets will reach their destinations (provided there's no ingress filtering), and the replies will not arrive.  Some applications do not need packets to return.  One can very well have a vehicle which streams the video of its front camera to some particular server in the Internet, and change its IP address at each access.  This does not require Mobile IP nor NAT.

I think it is impossible to stay meaningful in one phrase talking both Mobile Host and Mobile Router at the same time.  I think we need maybe two phrases.

> cannot cope with a change in the IP address of that Mobile Host [paste 
> socket error message here].
>
> arbitrary applications in the Hosts and Routers need to maintain their 
> IP address fixed regardless of the change of the IP address of the 
> Mobile Router, and the Access Router performs ingress filtering, and 
> reachability of these Hosts and Routers at a fixed IP address is  
> necessary.

Alex

> ^a LFN (because just 'host' may be confused with Mobile Host; and also 
> because within the moving network there is also one or several Routers 
> - not hosts.)
>

---

From: Brian Haberman <[email-masked]>
Date: Thu, 30 Jan 2014 17:47:51 -0500

Anthony,
     That's fine.

Regards,
Brian

On 1/30/14 1:46 PM, h chan wrote:
> The reason for this requirement is that in some existing mobility
> management deployment, in order to support those applications that
> does need network-layer mobility support, the mobile host uses HoA so
> that all the applications must use the HoA. Then it does not make it
> possible for an application to not use HoA.
> 
> So the bottom line in this revision is that the DMM solution only
> allows the possibility of not using the network-layer mobility
> support.
> 
> How to make use of this possibility is now not a part of this
> requirement. Therefore the requirement should avoid implication of
> such mechanisms.
> 
> possible to bypass it.
> -----Original Message----- From: Brian Haberman
> [mailto:[email-masked]] Sent: Thursday, January 30, 2014
> 8:02 AM To: h chan; [email-masked] Subject: Re: [DMM] AD Evaluation:
>>  after the first sentence) to say that network-layer mobility
>> support is not always needed in order to justify this capability.
>> 
>>  "it is possible to not invoke it" is to draw the contrast to using
>> it by default.
> 
> mobility support.  Is it envisioned that the application can signal
> the need for mobility support?  Does the user have to configure which

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 30 Jan 2014 15:18:19 -0800

On Jan 29, 2014, at 5:56 AM, Brian Haberman <[email-masked]> wrote:

[snip]

> existing security risks, that cannot be mitigated by existing security

Would work for me.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 30 Jan 2014 16:40:19 -0800

On Jan 29, 2014, at 6:01 AM, Brian Haberman <[email-masked]> wrote:

[snip]

> situations that a DMM solution would need to interact with, for example,

Your observation is correct. Maybe slightly better wording would work:

         The DMM solution may require loose, tight or no integration into
         existing mobility protocols and host IP stack. Independent of the
         integration level, the DMM solution MUST be able to co-exist with
         existing network deployments, end hosts and routers that may or
         may not implement existing mobility protocols. Furthermore, a DMM
         solution SHOULD work across different networks, possibly operated
         as separate administrative domains, when allowed by the trust
         relationship between them.

- Jouni

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 31 Jan 2014 12:43:06 +0100

Le 30/01/2014 20:53, h chan a écrit :
> Alex,
>
> I think the applications which work without MIP are the applications
> that can cope with the change of IP address of the MR. Is that
> correct?

Yes, that is correct for MH.

For the MR cases, any application running on the Host can cope with that
change (==TCP retransmits).

> Then mobility support is needed only for those applications that
> cannot cope with the change of IP address of the MR.

No, that is wrong.

IT depends what one means by 'mobility support' - on the MR or in the
network?

MR-based mobility support is needed on the MR for some kinds of
applications on Host to continue working.

Infrastructure-based mobility support is alternatively needed on the MR
for some kinds of applications on Host to continue working.

A mix of infrastructure-based mobility support and MR-based mobility
support is needed for some kinds of applications on Host to continue
working.

The 3 statements are valid simultaneously.

We can't just say that _only_ MR-based mobility support is needed.

> Is this MN sentence the same as: Mobility support is needed, for
> example, when a mobile host moves and an application cannot cope
> with a change in the IP address of the mobile host.

Right, same.

>> their IP address fixed regardless of the change of the IP address
>> of the Mobile Router, and the Access Router performs ingress
>> filtering, and reachability of these Hosts and Routers at a fixed
>> IP address is necessary.
>
> When the MR carries a network of hosts and routers, doesn't these
> routers in turn carry network so that at the final level of hosts,
> the applications are running there. If so, is it sufficient to state
> the applications in the hosts? (which includes hosts in the network
> of routers which are in turn in the network of the mobile router)

YEs, it is sufficient.

> So a host in the network of a router, which in turn is in the network
> of another router, which .... in the network of the mobile router can
> be called a host that moves with the mobile router.

YEs.

> Mobility support is also needed, for example, when a mobile router
> moves together and an application in a host that moves with the
                 ^ together with the Host
> mobile router cannot cope with a change of IP address of the mobile
> router.

YEs.

At this point we should say that [infrastructure-based, or MR-based, or 
a mix of the two] mobility support is needed, for example, when a Mobile 
Router moves together with the Host and an application on the latter is 
interrupted by the change of the IP address of the former.

(because we don't want that Host to cope with it; if we say 'can not 
cope' it's like if we wanted it to).

Alex

> possible to not use it.
> Mobility support is needed, for example, when a mobile host moves
> and an application cannot cope with a change in the IP address.
>
> Mobility support is also needed, for example, when a mobile router
> moves together and an application in a host which moves with the
> mobile router cannot cope with a change of IP address of the mobile
> router.
>
> a mobile node can often be stationary, and mobility support can also
> be provided at other layers. It is then not always necessary to
> maintain a stable IP address or prefix.
>
> One more alternative is to mention the "no need" case only without
> explaining the "needed" case as in the following. Yet if it is
> possible to state the "needed" case more concisely, it will be more
> clear to spell that out as in above.
>
> possible to not use it. Mobility support at the network-layer is not
> always needed; a mobile node can often be stationary, and mobility
> support can also be provided at other layers. It is then not always
> necessary to maintain a stable IP address or prefix.
>
> H Anthony Chan
>
>
> 2014 11:39 AM To: h chan; [email-masked] Subject: Re: [DMM] AD
>> host that moves with the router cannot cope with a change in the
>> IP address of the mobile node.
>
>> host or router that moves with that Mobile Router cannot cope with
>> a change in the IP address of the mobile host or of that Mobile
>> Router.
>
> Mobile Router is not that much influenced by the change of IP
> address of that MR.  When the MR changes its IP address, the Host
> feels it just like some other interruption in the path to another CN.
> These kinds of interruptions (link up/down) happen often in the
> fixed networks and yet Hosts continue to work.
>
> It is possible, for example, to have a Mobile Router move, have NAT
> (not mobility management), change IP address, and the Hosts and
> Routers in that moving network will continue working ok.
>
> It is also possible for MR to not have NAT, and forward packets with
> an address which is not topological correct in that network.  These
> packets will reach their destinations (provided there's no ingress
> filtering), and the replies will not arrive.  Some applications do
> not need packets to return.  One can very well have a vehicle which
> streams the video of its front camera to some particular server in
> the Internet, and change its IP address at each access.  This does
> not require Mobile IP nor NAT.
>
> I think it is impossible to stay meaningful in one phrase talking
> both Mobile Host and Mobile Router at the same time.  I think we
> need maybe two phrases.
>
>> their IP address fixed regardless of the change of the IP address
>> of the Mobile Router, and the Access Router performs ingress
>> filtering, and reachability of these Hosts and Routers at a fixed
>> IP address is necessary.
>
> Alex
>
>>
>> H Anthony Chan
>>
>> also because within the moving network there is also one or
>> several Routers - not hosts.)
>>
>>> an application (of a MN) may not be able to cope with a change
>>> in the IP address of the MN when the MN moves.
>>>
>>> H Anthony Chan
>>>
>>> [mailto:[email-masked]] Sent: Wednesday, January
>>> 29, 2014 12:30 PM To: h chan; [email-masked] Subject: Re: [DMM] AD
>>> I think in all descriptions it would be clearer if we just said
>>> MH when we meant Mobile Host and MR when we meant Mobile Router.
>>>
>>> There is a clear ambiguity in the 'mobile node' used above.
>>> Because if we talk moving networks then often the packets are
>>> destined (the contents of the destination address) to a LFN, not
>>> to the MR.
>>>
>>> may mean 'non-existent', some times it may mean light goes
>>> through it but modified.
>>>
>>>>
>>>
>>> when some applications prefer to not go through the HA in order
>>> to take advantage of the 4G pure speed.  When? For example if
>>> the HA link is too slow compared to 4G. (remark this is not the
>>> same as saying that the triangular route is longer than
>>> straight, because that is always true).
>>>
>>>>
>>>
>>>> Consider a video-call like appli: you want to be reachable
>>>> always at
>>> and understood what are the needs of applications, the
>>> distinctions MH-MR, etc.
>>>
>>>>
>>>
>>>>>> [email-masked] <mailto:[email-masked]>; Peter McCann Subject:
>>>>>> Re: [DMM]
>>> AD Evaluation:
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 31 Jan 2014 12:44:36 +0100

>> existing security risks, that cannot be mitigated by existing security

To me this is too hig-level.

IT's a good principle that we apply everywhere and it works.

But I wonder there is some detail about it.

Like for example: any new DMM solution involving route updates will not 
allow rogue routes to be inserted in the system.

Alex

---

From: Brian Haberman <[email-masked]>
Date: Fri, 31 Jan 2014 08:22:08 -0500

Hi Jouni,

>          relationship between them.

I am fine with this formulation.

Regards,
Brian

---

From: "Dapeng Liu" <[email-masked]>
Date: Fri, 31 Jan 2014 21:28:57 +0800

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Wednesday, January 29, 2014 9:57 PM
To: h chan; [email-masked]; [email-masked]; Peter
McCann

On 1/28/14 3:31 PM, h chan wrote:
> Rather the protection against such new vulnerablities can be limited to
the use of existing security protocols. It is okay to provide additional
means to protect against new risks as long as they do not require
development of new security protocols which are needed for DMM alone but are
not needed otherwise. Else a network deploying DMM versus a network not
deploying DMM will need additional security protocols which are not needed
otherwise.
> 
> 
> 
> So I think the word: "existing" security mechanisms/protocols is intended
to exclude protocols that are not needed otherwise.

A DMM solution MUST NOT introduce new security risks, or amplify existing
security risks, that cannot be mitigated by existing security mechanisms or
protocols.

Works for me.

Dapeng

Regards,
Brian

---

From: h chan <[email-masked]>
Date: Fri, 31 Jan 2014 21:12:09 +0000

How about the following to cut down the number of words:

   REQ2:  Bypassable network-layer mobility support

          DMM solutions MUST enable network-layer mobility but it MUST
          be possible to not use it.  Mobility support is needed, for
          example, when a mobile host moves and an application cannot
          cope with a change in the IP address.  Mobility support is
          also needed, for example, when a mobile router moves together
          with a host and an application in the host is interrupted by a
          change of IP address of the mobile router.  However mobility
          support at the network-layer is not always needed; a mobile
          node can often be stationary, and mobility support can also be
          provided at other layers.  It is then not always necessary to
          maintain a stable IP address or prefix.

H Anthony Chan

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, January 31, 2014 5:43 AM
To: h chan; [email-masked]
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

For the MR cases, any application running on the Host can cope with that change (==TCP retransmits).

No, that is wrong.

IT depends what one means by 'mobility support' - on the MR or in the network?

MR-based mobility support is needed on the MR for some kinds of applications on Host to continue working.

Infrastructure-based mobility support is alternatively needed on the MR for some kinds of applications on Host to continue working.

A mix of infrastructure-based mobility support and MR-based mobility support is needed for some kinds of applications on Host to continue working.

> example, when a mobile host moves and an application cannot cope with 
> a change in the IP address of the mobile host.

Right, same.

> routers in turn carry network so that at the final level of hosts, the 
> applications are running there. If so, is it sufficient to state the 
> applications in the hosts? (which includes hosts in the network of 
> routers which are in turn in the network of the mobile router)

YEs, it is sufficient.

YEs.

                 ^ together with the Host

YEs.

At this point we should say that [infrastructure-based, or MR-based, or a mix of the two] mobility support is needed, for example, when a Mobile Router moves together with the Host and an application on the latter is interrupted by the change of the IP address of the former.

(because we don't want that Host to cope with it; if we say 'can not cope' it's like if we wanted it to).

Alex

> Mobility support is needed, for example, when a mobile host moves and 
> an application cannot cope with a change in the IP address.
>
> However mobility support at the network-layer is not always needed; a 
> mobile node can often be stationary, and mobility support can also be 
> provided at other layers. It is then not always necessary to maintain 
> a stable IP address or prefix.
>
>> change in the IP address of the mobile host or of that Mobile Router.
>
> Mobile Router is not that much influenced by the change of IP address 
> of that MR.  When the MR changes its IP address, the Host feels it 
> just like some other interruption in the path to another CN.
> These kinds of interruptions (link up/down) happen often in the fixed 
> networks and yet Hosts continue to work.
>
> filtering), and the replies will not arrive.  Some applications do not 
> need packets to return.  One can very well have a vehicle which 
> streams the video of its front camera to some particular server in the 
> Internet, and change its IP address at each access.  This does not 
> require Mobile IP nor NAT.
>
>>> destined (the contents of the destination address) to a LFN, not to 
>>> the MR.
>>>

---

From: h chan <[email-masked]>
Date: Fri, 31 Jan 2014 22:24:54 +0000

Regarding the following:
6. I would like to avoid issues further along the publication chain, so I would like the editors to look at how the contributing authors are identified in the draft.  A good approach is described in the RFC Style Guide (https://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can be problematic.
------------------
I have now read the guidelines that the list of authors refer to those on the front page only. This draft had benefited from very valuable inputs from many people, so that I had in the past tried to give the deserved recognition to name more co-authors by listing their names inside. I managed to get around with the ietf template so that I thought it was possible. Yet I now found that it is not in compliance with the rfc guidelines. The relevant sections of the guidelines are pasted at the end. 

I apologize for not having read these guidelines before. In the future revision, other than the authors in the front page, I can only acknowledge the valuable inputs from all the rest as contributors together with contact information, and I am sorry for having caused the misunderstanding and especially if it hurts anyone's feeling now.

As the work of the requirements draft is drawing close to completion now, I thank everyone again for the very helpful and useful work. 

H Anthony Chan

----------------

Authors vs. Contributors 

Questions are still arising about the editorial policies on RFC authorship, and the contents of the first page, of the Contributors section, and of the Authors' Address section. We will attempt to clarify. 

1. When the RFC Editor refers to "authors", we mean exactly the set of names listed on the first page of an RFC. These people are considered to be equally responsible for the contents of the document, and all will be asked to read and approve the RFC before publication. 

2. When the RFC Editor refers to "contributors", we mean people, other than the authors, who also contributed significantly to the RFC. They should be listed in a Contributors section of the body of the document. 

3. The last section of the document has traditionally been a section listing contact information for authors. The intent of this section is to tell readers how to get in touch with those people responsible for the document, to seek clarification, make comments, etc. This section should include contact information for all authors. This section has been titled "Author's Address" (or "Authors' Addresses"). 

4. The issue has arisen: can/should the Contributors section include contact information? The answer is yes, it may include contact information at the authors' discretion. 

19 August 2003. Updated 18 October 2006. Updated 14 June 2011.

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Friday, January 24, 2014 11:30 AM
To: [email-masked]; [email-masked]; Peter McCann
Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements

All,

2. Introduction:

3. Section 3:

4. Section 4:

5. Section 5:

Regards,
Brian

---

From: h chan <[email-masked]>
Date: Sat, 1 Feb 2014 00:13:48 +0000

Alex,
There are some examples in the motivation following REQ6. Do you think the rouge route example is included in the "redirecting traffic from its legitimate path" or should it be added as a separate example?

          A DMM solution MUST NOT introduce new security risks, or
          amplify existing security risks, that cannot be mitigated by
          existing security mechanisms or protocols.

          Motivation: Various attacks such as impersonation, denial of
          service, man-in-the-middle attacks, and so on, may be launched
          in a DMM deployment.  For instance, an illegitimate node may
          attempt to access a network providing DMM.  Another example is
          that a malicious node can forge a number of signaling messages
          thus redirecting traffic from its legitimate path.
          Consequently, the specific node is under a denial of service
          attack, whereas other nodes do not receive their traffic.
          Accordingly, security mechanisms/protocols providing access
          control, integrity, authentication, authorization,
          confidentiality, etc. can be used to protect the DMM entities
          as they are already used to protect against existing networks
          and existing mobility protocols defined in IETF.

   This requirement prevents a DMM solution from introducing
   uncontrollable problems of potentially insecure mobility management
   protocols which make deployment infeasible because platforms
   conforming to the protocols are at risk for data loss and numerous
   other dangers, including financial harm to the users.

H Anthony Chan

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Friday, January 31, 2014 5:45 AM
To: [email-masked]
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

Le 31/01/2014 00:18, Jouni Korhonen a écrit :
>> existing security risks, that cannot be mitigated by existing 
>> security mechanisms or protocols.
>
>
> Would work for me.

Like for example: any new DMM solution involving route updates will not allow rogue routes to be inserted in the system.

Alex