Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules

From: Romain KUNTZ <[email-masked]>
Date: Mon, 3 Dec 2007 18:39:20 +0100

Hi Teco,

On 2007/11/27, at 10:26, Teco Boot wrote:
> What I found is:
> RFC4080 (NSIS Framework): 4.6.1.  Flow Identification
> draft-ietf-nsis-qos-nslp-15 (QoS NSLP): 5.1.3.5.  Packet Classifier
> (PACKET_CLASSIFIER)
>
> I think NSIS produced specifications on packet classification should  
> be
> verified for using for MIP flow distribution / handover also.
> Maybe RSVP TSPEC is past and NSIS FlowID is future.

 From what I understood in the envisionned architecture for flow  
distribution in MEXT (crrect me if I'm wrong):

1. an entity (could be the HA, or not) distributes policies to the MR  
and possibly the peers (e.g. HA) too,
2. The MR translates them to filter rules according to its current  
environment (available interfaces, path characteristics...),
3. The MR sends those filter rules to the peer (e.g the HA),
4. The peer enforce those filter rules.

For 1., we need to describe policies, and a transport protocol between  
peers (none specified so far).
For 2., we need to describe filter rules (e.g. draft-larsson-mext-flow- 
distribution-rules if we consider ASCII-defined filter rules, but this  
draft does not have companion transport protocol yet to fulfill 3.)
For 3., we need a transport protocol to bind filter rules to BIDs  
(draft-soliman-monami6-flow-binding was proposed, where flows are  
described as an option to fulfill 2., but this option was not  
specified yet.)

Here, where would the NSIS framework operate: on 3., for both  
transport and flow identification? But we still need to bind flows to  
BID.

Regards,

-- 
Romain KUNTZ
[email-masked]
Louis Pasteur University - Networks and Protocols Team

>> -----Oorspronkelijk bericht-----
>> Van: Hannes Tschofenig [mailto:[email-masked]]
>> Verzonden: dinsdag 27 november 2007 9:42
>> Aan: Teco Boot
>> CC: [email-masked]
>> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules
>>
>> Hi Teco,
>>
>> Teco Boot wrote:
>>> Hi Hannes,
>>> I suggest reusing what we already have.
>>> Maybe RSVP is already in place, in that case RSVP packets are sent
>> over the
>>> tunnel.
>>>
>>
>> Two observations from my limited RSVP experience:
>>
>> * Deployment of RSVP does not really exist (for this type of
>> environment). Please note that I talk about RSVP and not RSVP-TE.
>>
>> * RSVP for packet filter installation does not exist either as an  
>> IETF
>> document. There was only some work in the 3GPP2.
>>
>> The 3GPP2 has also specified the NSIS NATFW NSLP to perform packet
>> filter installation. Unlike RSVP for packet filter installation the
>> NSIS
>> NATFW NSLP is actually an IETF document.
>>
>>> In the MONAMI6 context; I think we need a protocol for signaling
>> traffic
>>> flow policy. This is related to MIP.
>>> Within this protocol, we need some kind of traffic specification,
>> here we
>>> could reuse RSVP TSPEC.
>>> Cheers, Teco.
>>>
>>
>>
>> Ciao
>> Hannes
>>
>>>
>>>> -----Oorspronkelijk bericht-----
>>>> Van: Hannes Tschofenig [mailto:[email-masked]]
>>>> Verzonden: maandag 26 november 2007 10:12
>>>> Aan: Teco Boot
>>>> CC: [email-masked]
>>>> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules
>>>>
>>>> Hi Teco,
>>>>
>>>> Teco Boot wrote:
>>>>
>>>>>>> Finally, what happened to
>>>>>>> draft-mitsuya-monami6-flow-distribution-policy-04.txt. I
>>>>>>> thought this was also going to be adopted as a MONAMI6 WG
>>>>>>> document. I might have missed some emails.
>>>>>>>
>>>>>>>
>>>>>> There are two documents about flow distribution languages
>> documents.
>>>>>> - draft-mitsuya-monami6-flow-distribution-policy-04.txt
>>>>>> - draft-larsson-monami6-filter-rules-02.txt
>>>>>>
>>>>>> We agreed to merge the two documents and
>>>>>> published draft-larsson-mext-flow-distribution-rules-00.txt
>>>>>>
>>>>>>
>>>>>>
>>>>> I suggested to check using RSVP TSPEC for flow-distribution-rules
>>>>>
>>>> before.
>>>>
>>>>> This has similar functionality and integration with upper layers
>>>>>
>>>> could be
>>>>
>>>>> more straightforward.
>>>>> I'm afraid I don't have time to work out this idea. I would
>>>>>
>>>> appreciate
>>>>
>>>>> someone picks up.
>>>>>
>>>>>
>>>> Are you suggesting to use RSVP for signaling the packet filters?
>>>> Or: Are you suggesting to look at the packet formats for describing
>> the
>>>> traffic filters?
>>>>
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>>> Teco.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MEXT mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>>>
>>>>>
>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 3 Dec 2007 19:20:27 +0100

Hi Romain,

For evaluating existing specifications for using in the steps that you
described, I think we should look for something that is highly related. 
I think flow specification for QoS handling and tunnel selection is very
similar. I don't know if this is the case for the other steps.

QoS reservation for tunneled flows within tunnel and for the tunnel itself
is somewhat related with tunnel selection. But I think using separate
protocols (e.g. RSVP and BU) is more optimal.

Some comments inline.

Teco.

> Van: Romain KUNTZ [mailto:[email-masked]]
> Verzonden: maandag 3 december 2007 18:39
> Aan: Teco Boot
> CC: Hannes Tschofenig; [email-masked]

I don't know what a policy is. I think you mean a profile for generating
filter rules. It could be filter rules itself also.

> environment (available interfaces, path characteristics...),

MR is MN or HA, correct?

> 3. The MR sends those filter rules to the peer (e.g the HA),

Or HA to MN, correct?

> 4. The peer enforce those filter rules.

For a bidirectional tunnel, there are two processes for two directions,
correct?

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 5 Dec 2007 15:41:25 +0100

Hi Teco,

Before commenting how we could apply already defined protocols to mip6  
flow distribution, let me explain further my thoughts to see if we are  
on the same tracks:

> filter rules. It could be filter rules itself also.

A policy is a general information that describes access network  
preferences, user and
operator preferences, security restrictions etc. Application of policy  
usually results in the definition of filter rules which implement the  
policy for specific traffic flows.

Filter rules are tightly related to the host that creates them, so I  
don't think filter rules can be distributed by a third-part node,  
whereas policies, that are more general, can.

>> environment (available interfaces, path characteristics...),

The MR or MN translates the policies to filter rules. Other peers  
(e.g. the HA) can use them later to confront them to the received  
filter rules from the MR/MN.

I don't see a use case where the HA or the CN could translate the MR/ 
MN's policies to filter rules, maybe someone have one?

>> 3. The MR sends those filter rules to the peer (e.g the HA),

Not in this architecture, because the HA does not know what is the  
MR's environment (e.g. what BIDs he uses on which interface, what are  
the interfaces characteristics and the characteristics of the network  
it connects to), and thus cannot create filter rules for the MR.

> For a bidirectional tunnel, there are two processes for two  

Of course the MR/MN also enforces the filter rules it has created and  
sent to the HA/CN.

To summarize, in the current mext architecture, the MR creates filter  
rules from policies (policies received by a third-part node), enforce  
them, and send them to the HA/CN, the HA/CN can then validate them  
against the policy, and enforce them.

Regards,

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 6 Dec 2007 00:05:26 +0100

> Verzonden: woensdag 5 december 2007 15:41
> Aan: Teco Boot
> CC: 'Hannes Tschofenig'; [email-masked]

OK, comments inline. 

> operator preferences, security restrictions etc. 

Monami6 policy is defined in larsson-monami6-filter-rules.
I am fine with your explanation.

> Application of policy

Ok.

> MN's policies to filter rules, maybe someone have one?

I prefer using MN, this is MN (MIPv6) or MR (NEMO).

I am not sure the MN generates the filter for peer (HA, CN) in all cases.
For example, HA / CN may have other policies. I think this is getting
complex and we should work out the basic approach first, that MN generate
the filter for both itself and for peer.

I remember someone brought up the HA generate filters in Chicago. Maybe it
was policies. Not in minutes.

> it connects to), and thus cannot create filter rules for the MR.

Same as above.

I do not understand why HA cannot create a filter. It is not about BIDs of
interfaces, it is only the filter rules. Again, not a discussion for today.

> Of course the MR/MN also enforces the filter rules it has created and

OK.

> against the policy, and enforce them.

OK, we are on same track.
Now we can make the next step, checking existing specifications for the
filter rules. I like to see references to documents with page numbers or
section numbers.

We have already:

draft-soliman-monami6-flow-binding-04.txt
3.1.  Flow Identification option

"PF: The OpenBSD Packet Filter"
<ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf>.

RSVP Filterspec (somewhere in RFC2205)

NSIS (somewhere in draft-ietf-nsis-nslp-natfw-16.txt)

Teco.

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Thu, 06 Dec 2007 09:10:18 +0900

Hi Teco,

Teco Boot Wrote:
[...]
> was policies. Not in minutes.

Maybe I said.

I think there is a case that an administrator of HA such as a network
operator wants to modify policies of MN for network congestion control.
In this case, HA translates own policies to filter rules according to
current environment of MN and enforce them.

Regards,
Kazuyuki.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 6 Dec 2007 04:44:18 +0100

> Van: Kazuyuki Tasaka [mailto:[email-masked]]
> Verzonden: donderdag 6 december 2007 1:10
> Aan: Teco Boot
> CC: 'Romain KUNTZ'; 'Hannes Tschofenig'; [email-masked]

And sends HA the filter rules to MN?

Teco.

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Thu, 06 Dec 2007 15:28:51 +0900

Hi Teco,

> And sends HA the filter rules to MN?

HA could be sent filter rules to MN.

But, as you said, this is getting complex.
Because there is a possibility that preferences of the user and
the operator conflict. In addition, the operator needs know
capability of MN to control traffic (usable interface, kinds of 
interface ...etc).

In flow-distribution-rules, to work out the basic approach,
the MR creates filter rules from policies. Policies are received
by a third-part node (could be the HA, or not) and Local Node.

Regards,
Kazuyuki.

---

From: "George Tsirtsis" <[email-masked]>
Date: Sat, 8 Dec 2007 02:56:47 +0000

Just to make sure this is clear, draft-soliman-monami6-flow-binding is
the same kind of flow definition (i.e., binary X-tuple definition)
with the RSVP Filterspec. The main difference is that draft-soliman
includes an SPI which I think is important to include for something
like this.

Not sure about draft-ietf-nsis-nslp-natfw. It seems IPv4 specific
although also using binary format. Not familiar enough with this to
know if it fits, however.

Regards
George

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 10 Dec 2007 11:25:51 +0100

Hi Teco,

> interfaces, it is only the filter rules. Again, not a discussion for  

Filter rules are IMHO tightly related to path identifiers, thus, in  
the case of MCoA, BID.

> 3.1.  Flow Identification option

Acutally in the latest version (-05), the flow id option changed and  
the flow description part is supposed to be described in another  
document (not defined yet).

> <ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf>.

Do you mean using the grammar that PF defines as a reference to define  
ASCII flow filters? I don't think it's a good idea. The problem with  
PF, netfilter or any OS packet filtering is that each it's really OS- 
dependent, ie the grammar depends on what is implemented in the kernel  
filtering framework.
The grammar also might be too complex for what we need (e.g. "--port  
80" could be replaced with just "80"  if we define strict order of the  
arguments fields).

> RSVP Filterspec (somewhere in RFC2205)

 From what I see, the FILTER_SPEC class only allows to perform a  
selection on the IPv6 source address and source port or flow label.

> NSIS (somewhere in draft-ietf-nsis-nslp-natfw-16.txt)

This would need to be adapted to IPv6 and its specificities (next  
header filed, flow label, etc.), so it might be better to define  
something from scratch.

I would also add draft-larsson-mext-flow-distribution-rules  that  
proposes a multihoming-specific grammar to define ASCII flow filters.

Regards,
Romain

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 10 Dec 2007 11:28:12 +0100

Hello Georges,

> includes an SPI which I think is important to include for something

RFC2207 defines RSVP Extensions for IPSEC Data Flows. But as I said in  
my other mail to Teco, the selectors defined by RSVP to define a flow  
might be

romain

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Dec 2007 11:40:15 +0100

> Filter rules are IMHO tightly related to path identifiers, thus, in 
The concept of "path identifiers" does not exist in IP.

Ciao
Hannes

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 10 Dec 2007 12:11:14 +0100

> The concept of "path identifiers" does not exist in IP.

I'm not sure what is your point here, but when you have multiple  
concurrent paths, you still need to associate each of them with an  
unique identifier. This is what the BID stands for in MCoA.

romain

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Dec 2007 12:17:07 +0100

The BID is not a path identifier. I just re-read the definition in 
http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-04

Btw, it is not a good idea of to use RFC 2119 language in the 
terminology section.

Ciao
Hannes

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 10 Dec 2007 12:34:26 +0100

On 2007/12/10, at 12:17, Hannes Tschofenig wrote:
> The BID is not a path identifier. I just re-read the definition in http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-04

Ok, path might not be the exact term to use in this context.
Maybe tunnel identifier is more suitable.

romain

>>>> Filter rules are IMHO tightly related to path identifiers, thus,  
>>>> in the case of MCoA, BID.
>>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Dec 2007 12:35:10 +0100

> Maybe tunnel identifier is more suitable.
Yep.

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 10 Dec 2007 18:10:18 +0100

Someone pointed me that I forgot to finish my sentence :)

On 2007/12/10, at 11:28, Romain KUNTZ wrote:
> RFC2207 defines RSVP Extensions for IPSEC Data Flows. But as I said  
> in my other mail to Teco, the selectors defined by RSVP to define a  
> flow might be

... might not be enough.

romain

---

From: Xiaoming Fu <[email-masked]>
Date: Mon, 10 Dec 2007 18:17:38 +0100

Hi,

> This would need to be adapted to IPv6 and its specificities (next header 
> filed, flow label, etc.), so it might be better to define something from 
> scratch.
> 

I don't think you're correct in spelling that draft-ietf-nsis-nslp-natfw 
is only concerned with IPv4 filters. To my knowledge it covers both IPv4 
and IPv6 cases. CC-ing the draft editor (Martin Stiemerling) for his 
additional information.
Xiaoming

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 11 Dec 2007 09:22:19 +0100

Hi,

The NATFW NSLP indeed supports IPv6 and IPv4.

Any specific reason, why come to the conclusion that IPv4 is  
supported only?

   Martin

Am 10.12.2007 um 18:17 schrieb Xiaoming Fu:

> I don't think you're correct in spelling that draft-ietf-nsis-nslp- 
> natfw is only concerned with IPv4 filters. To my knowledge it  
> covers both IPv4 and IPv6 cases. CC-ing the draft editor (Martin  
> Stiemerling) for his additional information.
> Xiaoming

[email-masked]

NEC Laboratories Europe - Network Research Division

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
London W3 6BL | Registered in England 2832014

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 12 Dec 2007 10:17:01 +0100

Hi Martin,

> Any specific reason, why come to the conclusion that IPv4 is  

Sorry for the confusion, I misread the draft. So if I understand  
correctly, IPv6 filter rules could be described with a MRI (as defined  
in draft-ietf-nsis-ntlp-14)?

romain

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 12 Dec 2007 13:29:59 +0100

Hi Romain,

> in draft-ietf-nsis-ntlp-14)?
Yes, that is right. You can signal any rule that is can be basically  
expressed with the MRI. Furthermore, there are a few extension to  
this in the NATFW NSLP, e.g., whether it is rule for allowing or  
denying flows.

   Martin

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 13 Dec 2007 13:41:29 +0100

Hi Martin,

> this in the NATFW NSLP, e.g., whether it is rule for allowing or  

I guess you refer to the Extended Flow Information Object. Not only we  
would like to allow/deny a flow, but we'd like also to specify a  
tunnel identifier for a specific flow. That may require to define a  
new object.

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 13 Dec 2007 23:56:09 +1000

> tunnel identifier for a specific flow. That may require to define a  

=> But the tunnel identifier is already known from the BU. So all you need
to do is to describe the flow, nothing else is needed AFAICS. 

Hesham