Subject: [Int-area] Lifting up a filter discussion from Monami6

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Feb 2007 14:59:42 +0200

I would like to lift up one issue from the Monami6 WG
to a more general discussion. Monami6 is developing an
extension to Mobile IPv6 / Nemo so that a mobile node could
register its presence in multiple locations simultaneously.
One of things that they expect to be able to do is to control
what traffic goes to what care-of address; this flow to this
address, and the other flow to that other address. Mobile nodes
can obviously decide by themselves what outgoing interface to use.
However, in order for a home agent to deal with return traffic
properly, the mobile node has to tell it what policy to
employ.

The working group has debated between a number of different
approaches for doing this. In one approach, draft-soliman-
monami6-flow-binding the mobile node adds a filter to a Mobile
IPv6 Binding Update to tell what traffic should use this binding.
Another approach, draft-larsson-monami6-filter-rules, decouples
the policy exchange from the mobility protocol. The policies are
exchanged at a different time (typically earlier) and carried by a
different protocol (in this case over UDP). Yet another draft,
draft-mitsuya-monami6-flow-distribution-policy also separates
the mobility protocol and policy transfer, and carries
the policies in HTTP.

Monami6 should of course decide how they want to design this.
But this may be an interesting debate from a more generic point
of view. Do we have input for them? For instance, are there needs
in HIP/Shim6/Mobike space for similar functionality? Should the
designs be tailored for each of these situations? Is there some
advantage or disadvantage in looking at a generic solution?
Would a generic solution be doable?

Without going into too much detail about the specific proposals
it seems that there are actually a number of different topics here:
- carrier protocol choice
- policy container format
- timing of the policy exchange
- securing the transfer
- etc

Thoughts?

Jari

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Thomas Narten <[email-masked]>
Date: Wed, 14 Feb 2007 08:48:52 -0500

Some quick thoughts.

1) This is a generic problem that is not specific to mobile IP. I
   think it would (generally) be a mistake to adopt approaches that
   are tightly coupled to the MIP protocols.

2) The overall topic of flow balancing has been discussed extensively
   over a long period of time in the transport community. It is a very
   hard problem, and seemingly simple approaches tend to come with a
   number of limitations/disadvantages. Please extend this call for
   input/participation to the TSV community (tsvwg, perhaps?).

Thomas

---

From: <[email-masked]>
Date: Wed, 14 Feb 2007 11:12:25 -0600

Jari,

At a high level, I think having a common mechanism & format for
this kind of functionality would be a really good thing.  I think that
this is applicable for MIPv6, NEMO, SHIM6, HIP, MoBIKE, etc. and
defining point solutions for each protocol would be a wrong way
to go.

I think the exact transport of the mechanism and security the
mechanism may be a protocol specific issue, if they are defined
within the specific protocols - however, it might be interesting
to define a common protocol / solution, if it would meet the
requirements of Monami (for example).  Has anyone done an
analysis if doing this in-band is prefered over out-of-band
(or visa-versa)?

A few comments below:

>I would like to lift up one issue from the Monami6 WG to a 
>more general discussion. Monami6 is developing an extension to 
>Mobile IPv6 / Nemo so that a mobile node could register its 
>presence in multiple locations simultaneously.
>address, and the other flow to that other address. Mobile 
>nodes can obviously decide by themselves what outgoing 
>interface to use.

I agree, which I think leads us to the point that the policy would
usually be more of a hint than a mandate.

>properly, the mobile node has to tell it what policy to employ.

Agreed

>Another approach, draft-larsson-monami6-filter-rules, 
>decouples the policy exchange from the mobility protocol. The 
>policies are exchanged at a different time (typically earlier) 
>and carried by a different protocol (in this case over UDP). 
>Yet another draft, 
>the mobility protocol and policy transfer, and carries the 
>policies in HTTP.
>
>But this may be an interesting debate from a more generic 
>point of view. Do we have input for them? For instance, are 
>there needs in HIP/Shim6/Mobike space for similar 
>functionality? Should the designs be tailored for each of 
>these situations? Is there some advantage or disadvantage in 
>looking at a generic solution?

I tend to think that re-use is a good thing here, so if there
are no show-stoppers, I'd suggest a common solution would be
good.

>Without going into too much detail about the specific 
>proposals it seems that there are actually a number of 
>different topics here:

I think those are some of the issues that need to be seen.  I'd
think that policy container format SHOULD be common across
protocols, and for the other bullets, based upon an analysis
of in-band vs. out-of-band signaling uses, the other bullets
can be sorted out.  If out-of-band signaling seems like a good
way forward, then all of the bullets should be made so that they
are usable by other protocols.  If we think that in-band signaling
is a requirement, then we could define the common container
format and then have protocol-specific solutions for the rest.

John

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 14 Feb 2007 12:16:44 -0500

I think following up with the Transport area is a good idea.
In particular, I've always thought that the monami6 work
overlaps with NSIS.  Both protocols transport packet
filters that affect the processing of packets.

I have also wondered how much of monami6 could be accomplished
with the use of multiple home addresses.  After all, I would 
expect each interface to have its own home address and applications
would need to bind themselves to the right home address to
function properly over a given link type.  In other words, it
is important to solve this problem even in the absence of 
a mobility management protocol.

-Pete

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 14 Feb 2007 21:21:50 +0100

Hi John,

> analysis if doing this in-band is prefered over out-of-band

There seems to be multiple opinions here.  Some analysis has
been done, leading to one of the monami6 proposals which
suggests out-of-band communication of filter rules: 
draft-larsson-monami6-filter-rules; but as mentioned there is
an alternative monami6 proposal which advocates in-band signalling,
so there isn't full consensus on this.

The main reason I see (as one of the authors of
draft-larsson-monami6-filter-rules) for doing this out-of-band
is that the timing of events which cause changes to the filter
rules seem to have little correlation with handover events in
monami6; and I would expect something similar for NEMO, SHIM6,
HIP and MOBIKE.

The actual *binding* of a particular filter rule to a particular
endpoint *will* change on handover, though; so it is important
to do the split between rule definition and endpoint binding
right to achieve proper decoupling.

<snip some good comments>

> format and then have protocol-specific solutions for the rest.

First a little note on terminology -- in the monami6 discussions,
we've tried to use the word 'policy' to cover a number of factors,
including user preferences, which could influence the choice (at
the MN) of paths for various traffic, while the actual rules conveyed
from MN to HA, which can be applied to the traffic flow, is referred
to as filter rules.  So rather than talk about policy container
format, I'd prefer to talk about filter rule container format...

Anyway, I'm in favour of the idea of making the filter rule
container format common across protocols, and I'd suggest that
in most cases, it would be appropriate to have a common defined
carrier protocol.  I'm sure we'll see cases where optimization
or other considerations will make it attractive to define in-band
filter rule transport, but if a common carrier protocol and
method for securing the transfer has already been defined, that
would hopefully be delta work, rather than complete re-invention.

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 14 Feb 2007 14:20:48 -0800

I would be sympathetic to developing something generic that works for
multiple protocols instead of just Mobile IP, while also keeping in mind
the issue of mobility and latency concerns associated with that. One
thing to take into account is that this exchange is not necessarily a
one-time exchange and policies and filters may change over time, based
on the current connection capabilities of an end host. In such cases,
some of this signaling may potentially be bound to handoffs and in the
context of Mobile IP or MOBIKE-like protocols, if this means separate
signaling exchanges before the flow changes can happen, it could be less
than useful. 

I had briefly discussed this with Dave Thaler in San Diego and we had
talked about defining the flow information in a generic format, perhaps
as an IPv6 extension header or as a Destination Option. If such an
approach were to be taken, this information could then be carried in any
protocol, which would get rid of additional signaling and latency
concerns associated with it. So, from this point of view, a couple of
different things would need to happen - an independent specification
needs to define such an extension header or destination option and the
fields that go into it; a different specification would then describe
how this is carried in a given protocol (say, Mobile IP) and how the
information is secured within that context. 

Thoughts on something like this? 

Vidya 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, February 14, 2007 5:00 AM
> To: Internet Area
> Cc: [email-masked]
> Subject: [Int-area] Lifting up a filter discussion from Monami6
> 
> 
> more general discussion. Monami6 is developing an extension 
> to Mobile IPv6 / Nemo so that a mobile node could register 
> its presence in multiple locations simultaneously.
> However, in order for a home agent to deal with return 
> traffic properly, the mobile node has to tell it what policy 
> to employ.
> 
> policies are exchanged at a different time (typically 
> earlier) and carried by a different protocol (in this case 
> over UDP). Yet another draft,

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 15 Feb 2007 00:08:56 +0100

> signaling exchanges before the flow changes can happen, it could be less

I don't know if you read my recent post, but we've analysed this and found
that there is very little correlation (basically none) between the time
when a filter rule update is needed, and the time of handover.

> Thoughts on something like this?

First, this cannot simply be described as 'flow information', so if
that was the context of your discussion, I don't think it is quite
relevant for this discussion.
 
Secondly, this assumes that the filter rules would consistently be
communicated to the end host at the other end of your regular traffic,
which is an assumption that doesn't generally hold for filter rules.

Thirdly, extension headers are for optional internet-layer information
(RFC 2460), and I'm not sure this is a fair categorization of such
filter rules as we're discussing here.  I don't know how much people
care about proper layering these days, though ...

Finally, although filter rules wouldn't necessarily be very large in
size, I doubt that the size constraints associated with extension
headers make it appropriate to put filter rules in an extension header.
Remember that extension headers belong to the unfragmentable part of
an IPv6 packet, so there's a variable maximum size for such a header,
(depending on the presence of other extension extension headers); it
seems as if it would create a silly size constraint for filter rules
to define their default transport to be an IPv6 extension header.

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 14 Feb 2007 19:57:54 -0800

Hi Henrik,
Sorry, due to some intermittent connectivity issues, it turned out that
even though my application had sent the email before receiving the other
responses, it was actually only sent out later.  

> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Wednesday, February 14, 2007 3:09 PM
> To: Internet Area
> Subject: Re: [Int-area] Lifting up a filter discussion from Monami6
> 
> 
> > multiple protocols instead of just Mobile IP, while also keeping in 
> > mind the issue of mobility and latency concerns associated 
> with that. 
> > One thing to take into account is that this exchange is not 
> > necessarily a one-time exchange and policies and filters may change 
> > over time, based on the current connection capabilities of an end 
> > host. In such cases, some of this signaling may potentially 
> be bound 
> > to handoffs and in the context of Mobile IP or MOBIKE-like 
> protocols, 
> > if this means separate signaling exchanges before the flow 
> changes can 
> > happen, it could be less than useful.
> 
> I don't know if you read my recent post, but we've analysed 
> this and found that there is very little correlation 
> (basically none) between the time when a filter rule update 
> is needed, and the time of handover.
> 

I went through your other email. I see that there may be little
correlation between filter rule updates and the time of handover in one
model of doing this. In other words, I think you are referring to a
model where there a bunch of rules set up in advance, say, with an ID
that maps to each rule and upon handoffs, it is the mapping of those IDs
to interfaces or IP addresses that needs to happen and not the actual
setting up or update of the rules itself. The rules could be updated at
any time (and perhaps somewhat infrequently), while the
rule-to-interface mapping is rather dynamic. I can subscribe to that
notion, although, the question I then have is whether we need to have a
certain protocol to set up the rules and other protocols to do the
rule-to-interface mapping. Having a separate protocol that sets up the
filter rules and updates the mapping would lead to the problem of having
to run that protocol separately at the time of handoff to update the
mapping. More notes below. 

> > talked about defining the flow information in a generic format, 
> > perhaps as an IPv6 extension header or as a Destination Option. If 
> > such an approach were to be taken, this information could then be 
> > carried in any protocol, which would get rid of additional 
> signaling 
> > and latency concerns associated with it. So, from this 
> point of view, 
> > a couple of different things would need to happen - an independent 
> > specification needs to define such an extension header or 
> destination 
> > option and the fields that go into it; a different 
> specification would 
> > then describe how this is carried in a given protocol (say, 
> Mobile IP) 
> > and how the information is secured within that context.
> > 
> First, this cannot simply be described as 'flow information', 
> so if that was the context of your discussion, I don't think 
> it is quite relevant for this discussion.
>  

No, that was a terminology issue - I was still referring to filter rules
exchange as well. 

> Secondly, this assumes that the filter rules would 
> consistently be communicated to the end host at the other end 
> of your regular traffic, which is an assumption that doesn't 
> generally hold for filter rules.
> 

We have to scope the problem here. As to what Monami6 is chartered to
solve, it is only the flow/binding policies exchange to/from the MN/MR
to the HA, very much in the context of MIP6 (and its variants) and NEMO.
Strictly from this perspective, tying this exchange to MIP6 signaling
should be acceptable. However, it seems fair to see if this can be done
a bit more generically in a way that allows this work to be useful for
something like MOBIKE, where the same kind of end hosts may be
participating in the exchange and the requirements and scope are quite
similar. 

However, if this were to be extended to an any-to-any policies/rules
exchange protocol, the scope and requirements become quite different.
That seems to fall under the scope of something that NSIS might be
doing. For instance, if this exchange is between two routers, the
information involved in this exchange and the timing and binding of the
information to interfaces or addresses become very different. Handoffs
are no longer a topic for consideration, for e.g. OTOH, batching of
information/rules, granularity of that and even the security models are
quite different. 

I don't think it is good to solve the router-to-router and
host-to-router/server/agent exchanges with the same approach. 

> Thirdly, extension headers are for optional internet-layer 
> information (RFC 2460), and I'm not sure this is a fair 
> categorization of such filter rules as we're discussing here. 
>  I don't know how much people care about proper layering 
> these days, though ...
> 

It depends on whether this is viewed as a layer violation or cross-layer
optimization :) I'm typically not a fan of layer violation. However, in
this case, I see the filter rules and policies as something that permits
QoS-aware IP routing. So, I don't particularly see a problem with this,
although I would like to hear more thoughts on this. 

> Finally, although filter rules wouldn't necessarily be very 
> large in size, I doubt that the size constraints associated 
> with extension headers make it appropriate to put filter 
> rules in an extension header.
> Remember that extension headers belong to the unfragmentable 
> part of an IPv6 packet, so there's a variable maximum size 
> for such a header, (depending on the presence of other 
> extension extension headers); it seems as if it would create 
> a silly size constraint for filter rules to define their 
> default transport to be an IPv6 extension header.
> 

>From RFC2460: 

"      The Unfragmentable Part consists of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

      The Fragmentable Part consists of the rest of the packet, that is,
      any extension headers that need be processed only by the final
      destination node(s), plus the upper-layer header and data." 

The extension header under discussion here is only to be processed by
the final destination node and hence, falls under the Fragmentable Part
- so, size is not an issue. 

Regards,
Vidya

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 15 Feb 2007 08:47:26 +0100

on 2007-02-15 04:57 Narayanan, Vidya said the following:
> rule-to-interface mapping is rather dynamic.

Yes.

> I can subscribe to that

This isn't a problem, it's what you want to do.  You want to de-couple
these two actions in time.  And that does not force you to define two
different protocols for it, although if there is some advantage to doing
so, as seems to be the case for monami6/mip6, you certainly can do so.

You probably should read the monami6 documents covering this if you're
not familiar with them, to show an example both of how and why this
could be the case.

> participating in the exchange and the requirements and scope are quite

??  I see no argument for placing this in an extension header here.

> information/rules, granularity of that and even the security models are

?? I still don't see any argument for placing this in and extension
header here.

> host-to-router/server/agent exchanges with the same approach. 

Oh?  Not that anyone has argued that either way, but as a general statement,
that would lead you to separate IP protocols, UDP protocols, TCP, etc., 
etc., for these exchanges.  I don't thing this statement is valid or
fruitful.

> optimization :)

No, it doesn't.

> I'm typically not a fan of layer violation. However, in

Even if there may be a relationship between filter rules and QoS, they
aren't the same thing, and mixing them together won't aid clear thinking.

> - so, size is not an issue. 

In that case, I'd like to point out, again, that the assumption that the
filter rules would consistently be communicated to the final destination
node at the other end of your regular traffic doesn't generally hold, and
also wonder why you feel the need to use the IP extension headers as a
replacement for UDP (or TCP/SCTP/DCCP).  What's the motivation?

This is a bad idea, not only from the viewpoint of layer violations, but
also from the viewpoint of not having any of the services built on top
of the transport protocols available, and from the point of view of the
implementor who can't then use the regular socket mechanism to handle
the communication of filters from one node to another.

	Henrik.

---

From: "Benjamin Lim" <[email-masked]>
Date: Fri, 16 Feb 2007 11:05:33 +0800

Hi,

Since Jari brought up this discussion, I would like to put forth an issue
about interworking Monami6 with NEMO. In Monami6, a mobile node knows the
traffic condition over its multiple links. Thus, the mobile node is able to
inform its home agent how to route the flow to the mobile node (through the
various filter rules setting methods proposed in the WG).

The mobile node now associates with a mobile router with multiple egress
paths (roaming into NEMO). However, the mobile node has no way of knowing
the existence of multiple paths (and their network characteristics) to
continue on with flow filtering. On the other hand, the mobile router cannot
perform efficient flow filtering since the mobile router has no way to know
the traffic requirements of the mobile node's flow. 

The fact is that the tunnel ends at the mobile router whereas the traffic
ends at mobile node cause such a problem with flow filtering. 

Any thoughts on how such issue can be solved?

Regards,
Benjamin Lim

> Sent: Wednesday, February 14, 2007 9:00 PM
> To: Internet Area

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 15 Feb 2007 19:44:28 -0800

Hi Henrik,
The discussion I had with Dave on this topic was something I wanted to
write to the Monami6 list about a while ago, so that the group can also
think about that. However, that somehow never happened and now that Jari
brought up this thread, I wanted to throw the idea out to see what
people think about it. I admit that I have not extensively thought about
it - so, this is not an attempt to promote any views. This is just a
discussion point. Dave mentioned it and on the surface, it seemed like
an idea worth exploring. 

I understand where you stand on the topic now and I would agree with
some of it and disagree with some other parts of it. Mainly,
irrespective of whether a transport protocol or extension headers or
mobility options are used to carry this information, I do not think we
should be aiming at a single solution for host-to-router and
router-to-router exchanges of filter rules, as I do believe the
requirements and security models are quite different in the two cases.
So, I think setting the scope at this level will be useful for starters.

I hope to continue an objective technical discussion and would also like
to see if others have any thoughts on this. 

Regards,
Vidya

> Sent: Wednesday, February 14, 2007 11:47 PM
> To: Narayanan, Vidya
> Cc: Internet Area
> > Sorry, due to some intermittent connectivity issues, it turned out 
> > that even though my application had sent the email before receiving 
> > the other responses, it was actually only sent out later.
> > 
> >> I don't know if you read my recent post, but we've 
> analysed this and 
> >> found that there is very little correlation (basically 
> none) between 
> >> the time when a filter rule update is needed, and the time of 
> >> handover.
> >> 
> > 
> > correlation between filter rule updates and the time of handover in 
> > one model of doing this. In other words, I think you are 
> referring to 
> > a model where there a bunch of rules set up in advance, 
> say, with an 
> > ID that maps to each rule and upon handoffs, it is the mapping of 
> > those IDs to interfaces or IP addresses that needs to 
> happen and not 
> > the actual setting up or update of the rules itself. The 
> rules could 
> > be updated at any time (and perhaps somewhat infrequently), 
> while the 
> > notion, although, the question I then have is whether we 
> need to have 
> > a certain protocol to set up the rules and other protocols 
> to do the 
> > filter rules and updates the mapping would lead to the problem of 
> > having to run that protocol separately at the time of handoff to 
> > update the mapping. More notes below.
> 
> This isn't a problem, it's what you want to do.  You want to 
> de-couple these two actions in time.  And that does not force 
> you to define two different protocols for it, although if 
> there is some advantage to doing so, as seems to be the case 
> for monami6/mip6, you certainly can do so.
> 
> You probably should read the monami6 documents covering this 
> if you're not familiar with them, to show an example both of 
> how and why this could be the case.
> 
> > No, that was a terminology issue - I was still referring to filter 
> > rules exchange as well.
> > 
> >> communicated to the end host at the other end of your regular 
> >> traffic, which is an assumption that doesn't generally hold for 
> >> filter rules.
> >> 
> > 
> > should be acceptable. However, it seems fair to see if this can be 
> > done a bit more generically in a way that allows this work to be 
> > useful for something like MOBIKE, where the same kind of 
> end hosts may 
> > be participating in the exchange and the requirements and scope are 
> > quite similar.
> 
> > information involved in this exchange and the timing and binding of 
> > the information to interfaces or addresses become very different. 
> > Handoffs are no longer a topic for consideration, for e.g. OTOH, 
> > batching of information/rules, granularity of that and even the 
> > security models are quite different.
> 
> ?? I still don't see any argument for placing this in and 
> extension header here.
> 
> Oh?  Not that anyone has argued that either way, but as a 
> general statement, that would lead you to separate IP 
> protocols, UDP protocols, TCP, etc., etc., for these 
> exchanges.  I don't thing this statement is valid or fruitful.
> 
> these days, 
> >> though ...
> > It depends on whether this is viewed as a layer violation or 
> > cross-layer optimization :)
> 
> No, it doesn't.
> 
> this case, I 
> > see the filter rules and policies as something that permits 
> QoS-aware 
> > IP routing. So, I don't particularly see a problem with 
> this, although 
> > I would like to hear more thoughts on this.
> 
> Even if there may be a relationship between filter rules and 
> QoS, they aren't the same thing, and mixing them together 
> won't aid clear thinking.
> 
> In that case, I'd like to point out, again, that the 
> assumption that the filter rules would consistently be 
> communicated to the final destination node at the other end 
> of your regular traffic doesn't generally hold, and also 
> wonder why you feel the need to use the IP extension headers 
> as a replacement for UDP (or TCP/SCTP/DCCP).  What's the motivation?
> 
> This is a bad idea, not only from the viewpoint of layer 
> violations, but also from the viewpoint of not having any of 
> the services built on top of the transport protocols 
> available, and from the point of view of the implementor who 
> can't then use the regular socket mechanism to handle the 
> communication of filters from one node to another.
> 
> 
> 	Henrik.
> 
> 
> 
> 
> 
> 
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 15 Feb 2007 19:46:24 -0800

Hi Thierry,
As I've just written in my email to Henrik, this was a discussion point
I was providing to discuss the feasibility of it. But, if it is
something people feel is viable, it will be a slightly different
approach from any of the proposed approaches thus far, yes. 

Vidya 

> From: Thierry Ernst [mailto:[email-masked]] 
> Sent: Thursday, February 15, 2007 4:20 AM
> To: Narayanan, Vidya
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> So, you are proposing a 4th solution if I got you right ?
> 
> Thierry.
> 
> 
> On Wed, 14 Feb 2007 14:20:48 -0800
> "Narayanan, Vidya" <[email-masked]> wrote:
> 
> >
> necessarily 
> >a one-time exchange and policies and filters may change over time, 
> >based on the current connection capabilities of an end host. In such 
> >cases, some of this signaling may potentially be bound to 
> handoffs and 
> >in the context of Mobile IP or MOBIKE-like protocols, if this means 
> >separate signaling exchanges before the flow changes can happen, it 
> >could be less than useful.
> >
> >approach were to be taken, this information could then be carried in 
> >any protocol, which would get rid of additional signaling 
> and latency 
> >> I would like to lift up one issue from the Monami6 WG to a more 
> >> general discussion. Monami6 is developing an extension to 
> Mobile IPv6 
> >> / Nemo so that a mobile node could register its presence 
> in multiple 
> >> locations simultaneously.
> >> One of things that they expect to be able to do is to control what 
> >> traffic goes to what care-of address; this flow to this 
> address, and 
> >> the other flow to that other address. Mobile nodes can obviously 
> >> decide by themselves what outgoing interface to use.
> over UDP). 
> >> Yet another draft, draft-mitsuya-monami6-flow-distribution-policy 
> >> also separates the mobility protocol and policy transfer, 
> and carries 
> >> the policies in HTTP.
> >> 
> >> But this may be an interesting debate from a more generic point of 
> >> view. Do we have input for them? For instance, are there needs in 
> >> HIP/Shim6/Mobike space for similar functionality? Should 
> the designs 
> >> be tailored for each of these situations? Is there some 
> advantage or 
> >> disadvantage in looking at a generic solution?
> >> Without going into too much detail about the specific proposals it 
> >> seems that there are actually a number of different topics here:
> --
> Thierry ERNST, PhD
> INRIA Rocquencourt France Project-Team IMARA / JRU LARA 
> http://www.lara.prd.fr +33 1 39 63 59 30 (office)
> 
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Feb 2007 05:50:26 +0100

> So, I think setting the scope at this level will be useful for starters.

I don't see any reason why there has to be different solutions for
host-to-router and router-to-router, but I also think that it's premature
to have a strong view on this until we've agreed both that the work is
worth doing in general and collected the requirements.

My primary interest right now is to see if it makes sense to work on a
common solution, or whether we should go back and complete the monami6
work for the needs expressed in the monami6 charter and base documents
only.

I think there is enough commonality with the needs of the protocols
mentioned earlier (HIP/Shim6/Mobike) that a common solution could be
considered for these.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Feb 2007 06:10:39 +0100

Hi Benjamin,

> Any thoughts on how such issue can be solved?

While the proposals discussed in monami6 so far has been geared to transfer
of filter rules, this seems to call for transfer not of filter rules, but
of a subset of policy declarations (some sort of preferences for quality
and cost of service) between the Mobile Router and the Node attaching to the
Mobile Network (the MNN).

I think that as a general problem, this may be less well understood, and
possibly more complex, than expressing filter rules.  The filter rules I
see needed by for instance monami6 appear to be a subset of filter rules
that can be expressed for firewalls today, using well-defined languages; but
I'm not aware of mature languages for expressing cost/latency/bandwidth/
/reliability/security/etc. preferences, and how to weigh them against each
other.

I know that some work has been done in SHIM6 on expressing and communicating
policy, but don't know that work well enough to know whether it would be
applicable to this case.

	Henrik

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 16 Feb 2007 15:27:51 +0100

Hi,

Do we need to keep ccing int-area (at the same time of Monami6) ?

The term "Mobile Node" is missleading. What Benjamin is talking about
is a Mobile Network Node (MNN).

So, the issue raised by Benjamin is known for a long time, even before
the set up of Monami6. The issue is discussed in
http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-07.txt
section 4.10, and the conclusion (section 5 same draft) is that the
issue is not specific to mobility at all (but is more important to be
solved in mobility scenarios). This is why it is not brought up to the attention of the Monami6 working group. 

However, since it is more important to be solved for Monami6 use case,
we could contemplate to solve it within Monami6, if interest arises. Of
course, the solution should not be specific to mobility since the
mobility protocol doesn't intervene between MR and MNN.

This issue is also worked out by the automotive industry, within ISO
TC204 WG16 (they have their own solution using SNMPv3).

Thierry.

On Fri, 16 Feb 2007 06:10:39 +0100
Henrik Levkowetz <[email-masked]> wrote:

>Monami6 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/monami6
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Feb 2007 16:16:48 +0100

Hi Thierry,

Since you're top posting, I'm not sure if you're responding to
Benjamin or me.

> Do we need to keep ccing int-area (at the same time of Monami6) ?

Depends on how general the issue is, I guess.

> is a Mobile Network Node (MNN).

Yes, and so am I, using that exact term, if you look again at my response
to Benjamin.

> attention of the Monami6 working group. 

Yes, it's covered in 4.10 of this document, to about the same level of
details as done in this thread so far.  However, the distinction between
filter rules and policies/preferences, which I believe is important in
this context, isn't covered there.

> TC204 WG16 (they have their own solution using SNMPv3).

Do you have more details about this, maybe a pointer to available documents?

	Henrik

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 16 Feb 2007 17:30:25 +0100

>Since you're top posting, I'm not sure if you're responding to

Actually, I was replying to Benjamin, but replying back using the last
mail on the thread ;-)

>this context, isn't covered there.

I don't know how important the distinction is, and so far I've only
heard and dealt with policies and preferences. They could be probably
be specified in whatever language (including proprietary) as long as
there is a transport to convey them between the two nodes. How this is
used at the MR is all internal and is not of interest from an IETF
standardization point of view. 

>Do you have more details about this, maybe a pointer to available documents?

Nop, the documents are not public. But here is their public website:
http://www.calm.hu/

Thierry.

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Feb 2007 20:13:42 +0100

Hi Thierry,

> Actually, I was replying to Benjamin, but replying back using the last

Ah. Ok.

...
> Nop, the documents are not public. But here is their public website:

Ok, thanks!  It does indeed look as if they are considering distribution
of preference policies within the system, but it doesn't look as if the
architecture requires a standardized protocol for transfer of preferences.
Hard to tell for certain, though, based on the information available on
the website.

	Henrik

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 19 Feb 2007 12:50:43 +0100

Hi Henrik,

>Hard to tell for certain, though, based on the information available on

What I can tell you is that they have their own solution, and this
solution is part of the CALM standard which is supposed to be deployed
in vehicles. So, this would be the standard solution within the vehicles
for ITS applications. They dot not necessarily need an IETF standard,
and don't even try, though they do reuse some of the existing standards
like NEMO Basic Support, etc. 

Thierry.

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 20 Feb 2007 04:43:36 +1100

Hi Jari, all,

After reading this email and reading all the responses I think a few
comments are in order.
Generally speaking, I would think that when given a choice between a "one
size fits all" solution versus one solution per protocol, most people would
choose the former. However, I don't think the choice is so simple as some of
the responses seemed to imply. 

I think it is ill-advised to take a decision on this without understanding
the scenarios, and the resulting requirements from those scenarios.
Additionally, we need to consider how each of the protocols using the
solution actually work. I'll list the scenarios we (authors of one of the
solutions) had in mind and let others comment or add their own scenarios.

Regardless of the approach, the solution we had in mind would transfer flow
descriptions and binding information between the flow in question and one or
more of the mobile node's addresses. The sender of this information is the
mobile node. The receiver is either a correspondent node or another
intermediate node. If we use the terms HA/MAP then we're implying the use of
MIPv6. So I'll stick to generic language. 

Now, each of the protocols you mention below (HIP, Mobike, SHIM6 ...etc)
have their own way of identifying the sending node to the receiver of the
signalling. This identity is obviously essential for securing the
signalling. Furthermore, they're all different in this regard. So I don't
think having one solution that fits all is a simple task. Even within one
protocol, the security requirements are different depending on the node
receiving the signalling. MIPv6 is the perfect example for this case. Can we
just assume that IPsec or AAA will work with a CN? I don't see how. Also,
some entities don't exist in all protocols, e.g. the HA/MAP.

So even if we go with "one solution" it would have to incorporate several
modes of operation (at least from the security perspective) to work for all
the different protocols. 

Another question to ask here is what is the real benefit of having one
solution? I'm not talking about saving documents, I mean a real benefit to
an implementer. If the flow descriptors need to have the same format then
that's easily done and reusable for implementers. But that doesn't require
one transport protocol. 

On the other hand, there are examples of protocols that incorporated the
same function without having to coordinate one protocol across the board. A
recent example is the use of IPv4 and IPv6 addresses in mobility protocols,
which was done in MIPv6, MIPv4 and I think shim6 without having to come up
with a single solution. 

Regardless of the outcome of this discussion, I hope we can get specific
with the comments that highlight the benefits of having one Vs several
solutions. I urge people to look at the bullets at the end of Jari's
original email and consider them when they make up their mind for one
approach Vs another. 

Hesham

---

From: Mark Townsley <[email-masked]>
Date: Mon, 19 Feb 2007 18:07:15 -0500

> router-to-router exchanges of filter rules, as I do believe the
And router to host? I'm afraid that it is fairly common for IPsec VPN 
clients to have filtering policy thrust upon them from the tunnel 
concentrator (e.g., whether split tunneling and such is permitted or not).

- Mark
>>>>> I would be sympathetic to developing something generic that
>>>>>           
>>>> works for
>>>>         
>>>>> multiple protocols instead of just Mobile IP, while also 
>>>>>           
>> keeping in 
>>     
>>>>> necessarily a one-time exchange and policies and filters 
>>>>>           
>> may change 
>>     
>>>>> over time, based on the current connection capabilities 
>>>>>           
>> of an end 
>>     
>>> rule-to-interface mapping. Having a separate protocol that 
>>>       
>> sets up the 
>>     
>>>>> I had briefly discussed this with Dave Thaler in San Diego
>>>>>           
>>>> and we had
>>>>         
>>>>> perhaps as an IPv6 extension header or as a Destination 
>>>>>           
>> Option. If 
>>     
>>>>> such an approach were to be taken, this information 
>>>>>           
>> could then be 
>>     
>>>>> a couple of different things would need to happen - an 
>>>>>           
>> independent 
>>     
>>>> First, this cannot simply be described as 'flow 
>>>>         
>> information', so if 
>>     
>>> We have to scope the problem here. As to what Monami6 is 
>>>       
>> chartered to 
>>     
>>> solve, it is only the flow/binding policies exchange 
>>>       
>> to/from the MN/MR 
>>     
>>> to the HA, very much in the context of MIP6 (and its 
>>>       
>> variants) and NEMO.
>>     
>>> Strictly from this perspective, tying this exchange to MIP6 
>>>       
>> signaling 
>>     
>>> However, if this were to be extended to an any-to-any 
>>>       
>> policies/rules 
>>     
>>> exchange protocol, the scope and requirements become quite 
>>>       
>> different.
>>     
>>>> Finally, although filter rules wouldn't necessarily be 
>>>>         
>> very large in 
>>     
>>>> Remember that extension headers belong to the 
>>>>         
>> unfragmentable part of 
>>     
>>>> an IPv6 packet, so there's a variable maximum size for 
>>>>         
>> such a header, 
>>     
>>>> (depending on the presence of other extension extension 
>>>>         
>> headers); it 
>>     
>>>> seems as if it would create a silly size constraint for 
>>>>         
>> filter rules 
>>     
>>>       extension headers that must be processed by nodes en 
>>>       
>> route to the
>>     
>>>       destination, that is, all headers up to and including 
>>>       
>> the Routing
>>     
>>>       header if present, else the Hop-by-Hop Options header 
>>>       
>> if present,
>>     
>>>       The Fragmentable Part consists of the rest of the 
>>>       
>> packet, that is,
>>     
>>> The extension header under discussion here is only to be 
>>>       
>> processed by 
>>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 19 Feb 2007 18:09:19 -0500

> defining point solutions for each protocol would be a wrong way
Just to add one more WG to the list, I believe pana had this discussion 
in the past as well and settled upon draft-ietf-pana-snmp, but was 
unwilling to commit to this being the *only* method.

- Mark

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 20 Feb 2007 00:48:23 +0100

Hi Mark,

...
> concentrator (e.g., whether split tunneling and such is permitted or not).

Ah!  That's one possible application of this I hadn't thought of, but
once mentioned it's (to me, at least!) a very interesting example of
how a standard filter description language could be useful.

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 19 Feb 2007 21:19:26 -0800

> From: Mark Townsley [mailto:[email-masked]] 
> Sent: Monday, February 19, 2007 3:07 PM
> To: Narayanan, Vidya
> Cc: Henrik Levkowetz; Internet Area
> > write to the Monami6 list about a while ago, so that the group can 
> > also think about that. However, that somehow never happened and now 
> > that Jari brought up this thread, I wanted to throw the idea out to 
> > see what people think about it. I admit that I have not extensively 
> > thought about it - so, this is not an attempt to promote any views. 
> > This is just a discussion point. Dave mentioned it and on 
> the surface, 
> > it seemed like an idea worth exploring.
> >
> And router to host? I'm afraid that it is fairly common for 
> IPsec VPN clients to have filtering policy thrust upon them 
> from the tunnel concentrator (e.g., whether split tunneling 
> and such is permitted or not).
> 

True. When I mentioned host-to-router, I had implicitly included the
other direction as well. I would imagine the filter specifications for
MOBIKE to fall under that category. I do think that the approaches for
MIP6, MOBIKE and perhaps SHIM6 (I'm less sure of this) share similar
requirements and having one solution may make sense. Would this cover
the VPN scenario that you have mentioned above? 

Vidya

> > I hope to continue an objective technical discussion and would also 
> > like to see if others have any thoughts on this.
> >
> > Regards,
> > Vidya
> >
> >   
> >> de-couple these two actions in time.  And that does not 
> force you to 
> >> define two different protocols for it, although if there is some 
> >> advantage to doing so, as seems to be the case for 
> monami6/mip6, you 
> >> certainly can do so.
> >>
> >> You probably should read the monami6 documents covering this if 
> >> you're not familiar with them, to show an example both of 
> how and why 
> >> this could be the case.
> >>
> >>     
> consistently be 
> extension 
> >> Oh?  Not that anyone has argued that either way, but as a general 
> >> statement, that would lead you to separate IP protocols, UDP 
> >> protocols, TCP, etc., etc., for these exchanges.  I don't 
> thing this 
> >> statement is valid or fruitful.
> >>
> >>     
> >> Even if there may be a relationship between filter rules and QoS, 
> >> they aren't the same thing, and mixing them together won't 
> aid clear 
> >> thinking.
> >>
> >>     
> >>> the final destination node and hence, falls under the 
> Fragmentable 
> >>> Part
> assumption that 
> >> the filter rules would consistently be communicated to the final 
> >> destination node at the other end of your regular traffic doesn't 
> >> generally hold, and also wonder why you feel the need to 
> use the IP 
> >> extension headers as a replacement for UDP (or TCP/SCTP/DCCP).  
> >> What's the motivation?
> >>
> violations, 
> >> but also from the viewpoint of not having any of the 
> services built 
> >> on top of the transport protocols available, and from the point of 
> >> view of the implementor who can't then use the regular socket 
> >> mechanism to handle the communication of filters from one node to 
> >> another.
> >>
> >>
> >> 	Henrik.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>     
> >

---

From: "Tero Kauppinen \(JO/LMF\)" <[email-masked]>
Date: Tue, 20 Feb 2007 10:29:44 +0100

Hi

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: 19. helmikuuta 2007 19:44
> To: 'Jari Arkko'; 'Internet Area'
> Subject: RE: [Int-area] Lifting up a filter discussion from Monami6
> 
> Hi Jari, all,
> 
> After reading this email and reading all the responses I 
> think a few comments are in order.
> Generally speaking, I would think that when given a choice 
> between a "one size fits all" solution versus one solution 
> per protocol, most people would choose the former. However, I 
> don't think the choice is so simple as some of the responses 
> seemed to imply. 
> 
> I think it is ill-advised to take a decision on this without 
> understanding the scenarios, and the resulting requirements 
> from those scenarios.
> Additionally, we need to consider how each of the protocols 
> using the solution actually work. I'll list the scenarios we 
> (authors of one of the
> Regardless of the approach, the solution we had in mind would 
> transfer flow descriptions and binding information between 
> the flow in question and one or more of the mobile node's 
> addresses. The sender of this information is the mobile node. 
> The receiver is either a correspondent node or another 
> intermediate node. If we use the terms HA/MAP then we're 
> implying the use of MIPv6. So I'll stick to generic language. 
> 
> Now, each of the protocols you mention below (HIP, Mobike, 
> SHIM6 ...etc) have their own way of identifying the sending 
> node to the receiver of the signalling. This identity is 
> obviously essential for securing the signalling. Furthermore, 
> they're all different in this regard. So I don't think having 
> one solution that fits all is a simple task. Even within one 
> protocol, the security requirements are different depending 
> on the node receiving the signalling. MIPv6 is the perfect 
> example for this case. Can we just assume that IPsec or AAA 
> will work with a CN? I don't see how. Also, some entities 
> don't exist in all protocols, e.g. the HA/MAP.
> 
> So even if we go with "one solution" it would have to 
> incorporate several modes of operation (at least from the 
> security perspective) to work for all the different protocols. 
> 
> Another question to ask here is what is the real benefit of 
> having one solution? I'm not talking about saving documents, 
> I mean a real benefit to an implementer. If the flow 
> descriptors need to have the same format then that's easily 
> done and reusable for implementers. But that doesn't require 
> one transport protocol.

What makes you think that it is only about the same format? If mobility
management protocols are able to stick to jobs that really belong to
mobility management protocols in contrast to extending them with the
management of filtering rules, I would say that it's more than just
about using the same format. If I, as an implementer of a mobility
protocol, don't have to consider the details of managing filter rules,
it has a visible impact on the implementation. If I, on the other hand,
would need to integrate my mobility protocol implementation into a
system where another mobility protocol is also doing filter rule
management of its own, I would say that my job is to a greater extend
more demanding. Eventually the system will start to evolve in such a way
that the filter rule management is pulled out to a common module in
which case I start thinking why would the mobility management protocol
be even bothered with the details of transferring filter rules. In my
scale saving a few bits/bytes weights considerably less than a better
overall design, i.e. stuffing everything into mobility signaling vs.
having one protocol more, but, on the other hand, that it just my scale.

Tero

> 
> On the other hand, there are examples of protocols that 
> incorporated the same function without having to coordinate 
> one protocol across the board. A recent example is the use of 
> IPv4 and IPv6 addresses in mobility protocols, which was done 
> in MIPv6, MIPv4 and I think shim6 without having to come up 
> with a single solution. 
> 
> Regardless of the outcome of this discussion, I hope we can 
> get specific with the comments that highlight the benefits of 
> having one Vs several solutions. I urge people to look at the 
> bullets at the end of Jari's original email and consider them 
> when they make up their mind for one approach Vs another. 
> 
> Hesham
> 
> 
>  > I would like to lift up one issue from the Monami6 WG  > 
> to a more general discussion. Monami6 is developing an  > 
>  > One of things that they expect to be able to do is to 
> control  > what traffic goes to what care-of address; this 
> flow to this  > address, and the other flow to that other 
> address. Mobile nodes  > can obviously decide by themselves 
> what outgoing interface to use.
> traffic  > properly, the mobile node has to tell it what 
> policy to  > employ.
>  >
>  > The working group has debated between a number of 
> different  > approaches for doing this. In one approach, 
> draft-soliman-  > monami6-flow-binding the mobile node adds a 
> filter to a Mobile  > IPv6 Binding Update to tell what 
> traffic should use this binding.
> decouples  > the policy exchange from the mobility protocol. 
> The policies are  > exchanged at a different time (typically 
> earlier) and carried by a  > different protocol (in this case 
> over UDP). Yet another draft,  > 
>  > the mobility protocol and policy transfer, and carries  > 
> the policies in HTTP.
>  >
> point  > of view. Do we have input for them? For instance, 
> are there needs  > in HIP/Shim6/Mobike space for similar 
> functionality? Should the  > designs be tailored for each of 
> these situations? Is there some  > advantage or disadvantage 
> in looking at a generic solution?
> proposals  > it seems that there are actually a number of 
> different topics here:

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Feb 2007 11:41:05 +0100

> - so, size is not an issue. 

 From a transport perspective I don't like seeing such sweeping 
statements that "size is not an issue". If you cause fragmentation of 
the packets by adding an extension header then you do effect the packet 
loss probabilities for the packet to reach the destination in a complete 
form.

Also if you know what the destination is, why not use a real transport 
protocol instead of reinventing the transport functionality you need 
inside the extension header. As I don't fully understand the 
requirements here I will not be to specific. But unless there is some 
real hard requirement why you need to place this exchange in the 
extension header, I would recommend using a transport protocol for the 
transport. It probably also makes the development of the security 
solution easier as there are more ready to use options on the transport 
layer.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 20 Feb 2007 22:46:26 +1100

> What makes you think that it is only about the same format? 

=> I look forward to more reasons.

 > If mobility
 > it has a visible impact on the implementation. 

=> First of all, what are those mobility management jobs and why is this
aspect not relevant to those jobs? Second, you *do* need to worry about flow
bindings regardless of the solution because even in the approach you
advocate only the transport protocol for the filters is independent, no? The
signalling for the flow binding is still included in the BU, at least in
MIPv6, or are you suggesting that you don't carry anything related to flows
in the BU, this includes mapping between flow id's and CoAs?

  If I, on the 
 > other hand,

=> I don't know which system you refer to above, but I think it's well
understood among people working in this area that there is a common module
handling flow descriptions and the policies associated between a flow and an
interface/CoA. This module can be indenpendent of the mobility protocol;
what we're discussing here is how to send this information to some other
node.

Hesham

---

From: "Tero Kauppinen \(JO/LMF\)" <[email-masked]>
Date: Tue, 20 Feb 2007 13:10:50 +0100

> => I look forward to more reasons.

Me too.

> 
>  > If mobility
>  > management protocols are able to stick to jobs that really 
> belong to  > mobility management protocols in contrast to 
> extending them with the  > management of filtering rules, I 
> would say that it's more than just  > about using the same 
> format. If I, as an implementer of a mobility  > protocol, 
> don't have to consider the details of managing  > filter 
> rules,  > it has a visible impact on the implementation. 
> 
> => First of all, what are those mobility management jobs and 
> why is this aspect not relevant to those jobs? 

Filter rules need not to be mobility management dependent.

> Second, you 
> *do* need to worry about flow bindings regardless of the 
> solution because even in the approach you advocate only the 
> transport protocol for the filters is independent, no? 

Not to the same extend.

The 
> signalling for the flow binding is still included in the BU, 
> at least in MIPv6, or are you suggesting that you don't carry 
> anything related to flows in the BU, this includes mapping 
> between flow id's and CoAs?

No, I'm not suggesting that. Naturally there needs be to some sort of a
link, but I'm just questioning the approach that it should be both the
mapping and the rule in which case changes to rules would always result
in mobility management signaling.

/Tero

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 20 Feb 2007 23:34:12 +1100

> in mobility management signaling.

=> That's fine, so please question the approach. It's best to have clear
questions/doubts to progress the discussion. Or feel free to respond to my
earlier comments. But it's hard to respond to statements like "A is better
than B" without an associated explanation.

Hesham

---

From: "Tero Kauppinen \(JO/LMF\)" <[email-masked]>
Date: Tue, 20 Feb 2007 13:55:17 +0100

> Sent: 20. helmikuuta 2007 14:34
> To: Tero Kauppinen (JO/LMF); 'Jari Arkko'; 'Internet Area'
>  > > signalling for the flow binding is still included in the 
> BU,  > > at least in MIPv6, or are you suggesting that you 
> don't carry  > > anything related to flows in the BU, this 
> includes mapping  > > between flow id's and CoAs?
>  >
>  > No, I'm not suggesting that. Naturally there needs be to  
> > some sort of a  > link, but I'm just questioning the 
> approach that it should  > be both the  > mapping and the 
> rule in which case changes to rules would  > always result  > 
> => That's fine, so please question the approach. It's best to 
> have clear questions/doubts to progress the discussion. Or 
> feel free to respond to my earlier comments. But it's hard to 
> respond to statements like "A is better than B" without an 
> associated explanation.

I think that separating filter rules as much as possible from mobility
management protocols (mmp) is good because:

* integrating a new mmp to the framework is easier because the impact on
the mmp is kept minimal
* changes in filter rules do not always necessitate additional mmp
signaling, signaling of course but not mmp signaling
* filter rules can be distributed to nodes (or received from nodes) that
would not normally receive mmp signals from the terminal (or would not
send mmp signals to the terminal)

I fully acknowledge that these present just my personal opinions because
one of the tricky aspects in this whole vs. discussion is that I think
it is possible get both approaches to work.

/Tero

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Feb 2007 10:15:34 -0800

Hi Magnus,

> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Tuesday, February 20, 2007 2:41 AM
> To: Narayanan, Vidya
>  From a transport perspective I don't like seeing such 
> sweeping statements that "size is not an issue". If you cause 
> fragmentation of the packets by adding an extension header 
> then you do effect the packet loss probabilities for the 
> packet to reach the destination in a complete form.
> 
> Also if you know what the destination is, why not use a real 
> transport protocol instead of reinventing the transport 
> functionality you need inside the extension header. As I 
> don't fully understand the requirements here I will not be to 
> specific. But unless there is some real hard requirement why 
> you need to place this exchange in the extension header, I 
> would recommend using a transport protocol for the transport. 
> It probably also makes the development of the security 
> solution easier as there are more ready to use options on the 
> transport layer.
> 

There are a couple of problems here. First, if UDP is going to be the
choice of transport protocol, reliability is still an issue. Next, the
following are additional considerations: 

* While it is feasible to decouple the filter rule exchange from handoff
times, in a mobile environment, the mapping of a particular filter rule
to an IP address or interface must be communicated during handoff. Even
if a standalone protocol is used to exchange filter rules, this mapping
must be conveyed in each specific protocol to minimize handoff signaling
and delay. 

* The above leads to the fact that different security solutions are then
needed to secure the filter exchange and the actual mappings - the
latter can use the security solution in place for the mobility
management protocol, while the former needs its own solution. 

The real problem here seems to be that MIP6 (and associated protocols
such as NEMO), for good or bad, has chosen the path of being part of the
IP layer rather than running at the transport layer. Since the mapping
of filter rules to addresses (not defining or exchanging the rules
itself, but, the mapping) is very much part of a handoff problem, it
needs to be integrated with the protocol for optimal operation during
handoffs. One option on the table is the use of mobility options (which
is an option to the Mobility Header, which is also an IPv6 extension
header) - that would make this applicable only to the MIP6 class of
protocols. If we want MOBIKE or Shim6 to be able to use it, I was
suggesting looking into defining its own IPv6 extension header, since
that can be carried in any of these protocols (except MOBIKE over IPv4).

Regards,
Vidya

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Feb 2007 20:54:42 +0200 (EET)

> that can be carried in any of these protocols (except MOBIKE over IPv4).

If I recall correctly, the issue of piggybacking arbitrary data on 
signalling messages was deferred from MIPv6 specifications, and hasn't 
been solved in later extensions or other protocols either. This is 
likely to bring up issues with different application PDU sizes, PMTUD, 
etc.

Maybe filter signalling is sufficiently more restricted case of 
piggybacking arbitrary data that devising framing, PMTUD, etc. for it 
is simpler.  I might agree with that if the filters were restricted to 
be (say) less than 500 bytes so that no fragmentation was never 
needed.

While solving the more general problem might be useful, it's not clear 
to me yet whether the requirements in this mobility space are strong 
enough to preclude using a more generic transport protocol.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 21 Feb 2007 08:40:14 +1100

> been solved in later extensions or other protocols either. 

=> Correct, it was actually deliberately removed from the spec for good
reasons IMO.

This is 
 > piggybacking arbitrary data that devising framing, PMTUD, 

=> It's not actually piggybacking in the case of MIPv6, it's part of the
mobility header itself.

Hesham

 > etc. for it

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 21 Feb 2007 09:21:42 +1100

> management protocols (mmp) is good because:

=> I think the keyword above is "as much as possible". Because as you know,
in the "one solution" approach, you *do* add extensions to the mmp. More
below. 

 > * integrating a new mmp to the framework is easier because 

=> This becomes an implementation issue. The "minimal" impacts you refer to
are based on the assumption that the flow descriptors are defined in your
mobility module. This need not be the case as I mentioned earlier. The
mobility protocol can simply be a carrier for this information. So one could
have a generic module with a generic API to any mobility protocol. The
format of the option can also be the same if needed. 

 > signaling, signaling of course but not mmp signaling

=> Changes in filters will necessitate signalling. what difference does it
make whether this signalling is done in mmp or not?

 > send mmp signals to the terminal)

=> That's false. What's the point of sending filter rules that describe a
flow without binding that flow to an address?? If you're binding that flow
to an address in your generic signalling then you've invented a new mobility
protocol that runs on top of whatever you already have. 

 > it is possible get both approaches to work.

=> I'm glad you listed those points. It's clear to me that more detail is
needed in this discussion to clarify the issues to others on the list.

Hesham

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Feb 2007 14:56:48 -0800

> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Tuesday, February 20, 2007 10:55 AM
> To: Narayanan, Vidya
> Cc: Magnus Westerlund; Internet Area
> > such as NEMO), for good or bad, has chosen the path of 
> being part of 
> > the IP layer rather than running at the transport layer. Since the 
> > mapping of filter rules to addresses (not defining or 
> exchanging the 
> > rules itself, but, the mapping) is very much part of a handoff 
> > problem, it needs to be integrated with the protocol for optimal 
> > operation during handoffs. One option on the table is the use of 
> > mobility options (which is an option to the Mobility 
> Header, which is 
> > also an IPv6 extension
> If I recall correctly, the issue of piggybacking arbitrary 
> data on signalling messages was deferred from MIPv6 
> specifications, and hasn't been solved in later extensions or 
> other protocols either. This is likely to bring up issues 
> with different application PDU sizes, PMTUD, etc.
> 
> Maybe filter signalling is sufficiently more restricted case 
> of piggybacking arbitrary data that devising framing, PMTUD, 
> etc. for it is simpler.  I might agree with that if the 
> filters were restricted to be (say) less than 500 bytes so 
> that no fragmentation was never needed.
> 

Maybe I am missing something here, but, how does UDP help with
fragmentation? The alternative proposed at the transport layer seems to
be UDP-based. 

> While solving the more general problem might be useful, it's 
> not clear to me yet whether the requirements in this mobility 
> space are strong enough to preclude using a more generic 
> transport protocol.
> 

In a mobile environment, the mobile node is in the best position to
determine the mapping of filter rules to addresses based on currently
available interfaces and connection conditions. This could be fairly
dynamic and I can see a need to exchange this upon handoff to
communicating devices (such as the HA or VPN GW or even a CN). 

Vidya

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 21 Feb 2007 00:57:14 +0100

on 2007-02-20 23:56 Narayanan, Vidya said the following:
...
> fragmentation? The alternative proposed at the transport layer seems to

No.  Jari raised the question of whether a more general filter
definition language would be a good idea (my paraphrasing), and
you proposed that IPv6 extension headers should be used as
transport for it.  Nobody else has proposed a specific transport
yet in this discussion.  

Personally I'd support something which uses an existing generic
transport protocol, such as UDP or SCTP; with DTLS security for
instance; but I'm not too concerned with the exact pick of such
a protocol.  What I'm very concerned about is the idea of moving
something which can both easily and reasonably be carried by an
existing generic transport protocol down into IPv6 extension
headers, when there's no evidence or arguments that doing so would
be particularly sensible or beneficial.

(Now, if somebody here had indeed proposed UDP as transport in
this discussion, I'd like to repeat something which Magnus
already hinted at, which is that it's still quite a difference
between what you can fit into a UDP package, and what you can add
in an IP header to a package which already carries a payload,
before fragmentation of that package occurs.)

> communicating devices (such as the HA or VPN GW or even a CN).

You keep ignoring the information that an analysis of the origins
of filter rule changes show them to be uncorrelated with handover
events.

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Feb 2007 16:14:12 -0800

> Sent: Tuesday, February 20, 2007 3:57 PM
> To: Narayanan, Vidya
> Cc: Pekka Savola; Internet Area
> >> signalling messages was deferred from MIPv6 specifications, and 
> >> hasn't been solved in later extensions or other protocols either. 
> >> This is likely to bring up issues with different application PDU 
> >> sizes, PMTUD, etc.
> >> 
> >> is simpler.  I might agree with that if the filters were 
> restricted 
> >> to be (say) less than 500 bytes so that no fragmentation was never 
> >> needed.
> >> 
> > 
> > fragmentation? The alternative proposed at the transport 
> layer seems 
> > to be UDP-based.
> 
> No.  Jari raised the question of whether a more general 
> filter definition language would be a good idea (my 
> paraphrasing), and you proposed that IPv6 extension headers 
> should be used as transport for it.  Nobody else has proposed 
> a specific transport yet in this discussion.  
> 

Okay. I was going with Jari's original email on this thread, in which he
talked about one existing proposal of doing this over UDP. 

> Personally I'd support something which uses an existing 
> generic transport protocol, such as UDP or SCTP; with DTLS 
> security for instance; but I'm not too concerned with the 
> exact pick of such a protocol.  What I'm very concerned about 
> is the idea of moving something which can both easily and 
> reasonably be carried by an existing generic transport 
> protocol down into IPv6 extension headers, when there's no 
> evidence or arguments that doing so would be particularly 
> sensible or beneficial.
> 
> (Now, if somebody here had indeed proposed UDP as transport 
> in this discussion, I'd like to repeat something which Magnus 
> already hinted at, which is that it's still quite a 
> difference between what you can fit into a UDP package, and 
> what you can add in an IP header to a package which already 
> carries a payload, before fragmentation of that package occurs.)
> 
> >> While solving the more general problem might be useful, it's not 
> >> clear to me yet whether the requirements in this mobility 
> space are 
> >> strong enough to preclude using a more generic transport protocol.
> >> 
> > 
> You keep ignoring the information that an analysis of the 
> origins of filter rule changes show them to be uncorrelated 
> with handover events.
> 

I was only referring to the mapping of filter rules to addresses here,
not the exchange of filter rules themselves. 

Vidya

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Wed, 21 Feb 2007 14:57:12 +0900

Hi Jari,

Thanks for starting this discussion.

> - carrier protocol choice

Unless the sender and receiver agree to use one transport protocol,
it can be any protocol.
Operators can pick one of existing secure transport protocol.
I don't have strong motivation to pick one transport protocol.
This decision depends on how system or application treat the timing  
of the exchange, too.

> - policy container format

Regardless of transport protocol, filter and policy should be ideally  
described in a common format.

If we assume running HIP/SHIM/MIP with policy at the same node,
we should consider the policy and filter "race" among those three  
protocols.
How we can convert policies derived from different protocols to a  
filter set is big problem here.
At least, a common way to "describe" filter and policy is useful to  
coordinate the filter set.

If MIP-filter scheme has the field-A for the policy description, but  
other-filter schemes don't have field-A, or
if one has the field-X with meaning-X, but others have the same field  
with different meaning,
these are the worst case.

> - timing of the policy exchange

This depends on application.
One application needs to send policy from operators (i.e. HA in  
MIP6), but some other want to set policy from clients (MN/MR).

In addition, some application doesn't support dynamic policy exchange.
Some sets of policy are statically configured on  MN and HA, and is  
dynamically switched according to the path availability.

Trigger of filter change must be promptly operated like the same  
timing of BU/BA in MIP6,
but trigger of policy exchange is not necessary operated at the same  
time.

> - etc

I actually want to see more comments from SHIM6, HIP, Mobike.
regards,
ryuji

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 Feb 2007 12:15:56 +0200 (EET)

> fragmentation? The alternative proposed at the transport layer seems to

If a packet carries data or signalling from a single application only, 
handling correct packetization of data that application may wish to 
send is rather straightforward because just one application needs to 
be concerned.

If a packet may carry data from multiple sources (e.g., MIPv6, 
filters, even arbitrary applications) every one of these will need to 
be involved and interact in the packetization process.

However, the second case gets simpler if you'd use MTU=1280, disable 
PMTUD, and fragment every packet that exceeds the MTU without trying 
to optimize the payloads such that no fragmentation was necessary.

Maybe this was the model you were suggesting and a reason for the 
disconnect.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 21 Feb 2007 22:08:05 -0800

> Sent: Wednesday, February 21, 2007 2:16 AM
> To: Narayanan, Vidya
> If a packet carries data or signalling from a single 
> application only, handling correct packetization of data that 
> application may wish to send is rather straightforward 
> because just one application needs to be concerned.
> 
> If a packet may carry data from multiple sources (e.g., 
> MIPv6, filters, even arbitrary applications) every one of 
> these will need to be involved and interact in the 
> packetization process.
> 
> However, the second case gets simpler if you'd use MTU=1280, 
> disable PMTUD, and fragment every packet that exceeds the MTU 
> without trying to optimize the payloads such that no 
> fragmentation was necessary.
> 
> Maybe this was the model you were suggesting and a reason for 
> the disconnect.
> 

Ah! Yes, I didn't think the payloads will be optimized to avoid
fragmentation. Also, I'm not sure if the filter rules in this case would
be handled as a separate application. Perhaps each application (MIP6 or
MOBIKE or SHIM6) that would carry the filter rules would have to handle
processing of the same? Ultimately, the filter rules are meant to be
used by one of these applications anyway. 

Vidya