Subject: [NSIS] Filters for the flow specification for the measurement in the Metering NSLP

From: Ali Fessi <[email-masked]>
Date: Fri, 21 Oct 2005 13:28:58 +0200

Dear all,

while updating the M-NSLP drafts, we had a discussion about how flexible 
should the flow specification be for the flows to be measured.

The current text in

http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-02.txt

says:

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

Section: 4.2.6.1  The <Filters> Object

    <Filters> restricts the set of considered flows for the metering.
    The MSPEC MUST support a value for <Filters> that is different from
    the flow information kept at GIST. In particular, <Filters> could be 
for example, a 5-tuple where one or more fields are wild-carded.

    For example, it MUST be possible to count all TCP SYN packets or all
    ICMP packets going to a given destination IP address.

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

However, we are currently questionning this statement.

The reason is whether it makes sense to use NSIS for the configuration 
of Metering Entities on the path from A to B to measure characteristics 
of other flows than the ones going from A to B.

I would like to ask you for your opinion on this topic:

- do you think that the specification of the flows to be measured should 
be restricted to the MRI from GIST.

-Or do you think it should be as flexible as possible?

Best regards,
Ali.

-- 
Ali Fessi
University of Tuebingen, Germany

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

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 21 Oct 2005 14:37:58 +0200

Hi Ali,

This is an interesting question:

Shall NSIS signaling be used to signal something that is not
directly related to the traffic flow specified by the MRI?

We would signal along a certain path (given by the MRI)
but affect something different, for example

    "Please measure along the path specified by the MRI all traffic
     that is directed to the IP address of my neighbor's PC"

This enters a new area of path-coupled signaling
that was not covered by NSIS so far.

A non-critical case would be just further restricting the MRI.
In the case of using NSIS to configure traffic measurement
this would mean measuring just a specified subset of the
packets identified by the MRI. This should be no problem.

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

--On 21.10.2005 13:28 Uhr +0200 Ali Fessi wrote:

> Dear all,
>
> while updating the M-NSLP drafts, we had a discussion about how flexible should the flow specification be for the flows to be measured.
>
> The current text in
>
>     the flow information kept at GIST. In particular, <Filters> could be for example, a 5-tuple where one or more fields are wild-carded.
>
> The reason is whether it makes sense to use NSIS for the configuration of Metering Entities on the path from A to B to measure characteristics of other flows than the ones going from A to B.
>
> - do you think that the specification of the flows to be measured should be restricted to the MRI from GIST.
>

---

From: Roland Bless <[email-masked]>
Date: Fri, 21 Oct 2005 21:42:39 +0200

Hi Ali,

(comments inline)

>    ICMP packets going to a given destination IP address.

The MF classifier definition from RFC 2475 is quite generic
and could possibly be referenced here.

> of other flows than the ones going from A to B.

That's an interesting question. On one hand this may be error prone,
but see examples below.

> -Or do you think it should be as flexible as possible?

IMHO it would be good to be at least more flexible in the sense that
you're interested in a subset of the aggregate that is defined
by the MRI between A and B. For example, I think it is perfectly
legitimate to measure or sample only certain TCP packets (as in your
example above) or certain ICMP messages or even particular HTTP
messages.
So the MRI would match an aggregate flowing from A to B, and you're
interested in a particular sub aggregate within. So the logic within
the NSLP could check the semantics, i.e. whether the filter is
actually picking a subset of the MRI.

OTOH I can imagine a scenario where you are configuring
filter for packets that are normally and currently *not*
flowing on the path from A to B. So the filter would be
used to detect/measure some failure conditions or anomalies. In this
case it would be even useful to configure filters along
A->B so that they match flows that are currently not routed
along that path.

Best regards,
 Roland

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 21 Oct 2005 22:24:27 +0200

Hi Roland,

> actually picking a subset of the MRI.

In this case we can save implementing a lot of logic by
specifying that the filter of the NSLP is applied in addition
to the filter defined by the MRI. Then you would only need
to specify port=80 or TCP_SYN_FLAG=1, respectively.
This would also be less error prone.

    Juergen

---

From: Roland Bless <[email-masked]>
Date: Sat, 22 Oct 2005 22:48:40 +0200

Hi Juergen,

> This would also be less error prone.

Yes, that's basically the idea. The MRI contains
a port number already, but no TCP flags, IGMP types and so on.
A separate full filter spec could, however, be useful for the
last scenario that I described (e.g. to detect anomalies).

Regards,
 Roland

---

From: Ali Fessi <[email-masked]>
Date: Mon, 24 Oct 2005 16:59:06 +0200

Hi Roland, hi Juergen and all,

> A->B so that they match flows that are currently not routed

both scenarios sound meaningful to me. I'm also in favor a flexible flow 
specification in the MSPEC and think it would give the Metering NSLP a 
broader applicability. But I currently see the following challenges:

- verifying the semantic of the flow specification in the MSPEC and its 
relationship to the MRI will be scenario dependant which will make it 
more complex and error prone

- Authorizing Metering NSLP configuration messages with a flexible flow 
spec will be also more complex, since the whole MSPEC needs to be 
verified against a set of security policies which will be also dependant 
on the application scenario and can not be generalized.

- NAT traversal: when crossing a NAT, the flow specification in the 
MSPEC will need to be updated. This means that the M-NSLP will need to 
look for the fields in the flow spec that need to be modified and modify 
them correctly according to the NAT binding. This might be not easy, if 
e.g. some port ranges and IP address netmasks, etc.

Looking at these issues, it seems to be a hard job to solve them and I'm 
currently not sure what is the best solution?!

Any comments are welcome!

Best regards,
Ali.

---

From: Thomas Herzog <[email-masked]>
Date: Mon, 24 Oct 2005 17:36:17 +0200

Hi, all,

I am currently implementing GIST Message Association setup and stumbled a 
little over section 4.3.2, concerning the adjacency-check which should be 
done in GIST responder node:

>    Even when a message relates to a local signaling application, an
>    adjacency MAY be required based on signaling application policy, and
>    the application of this policy MAY depend on the NSLP payload.
>    Therefore, when this decision has to be made, the NSLP payload is
>    delivered and the signaling application has two options:
> 
>    o  to proceed setting up the adjacency.  The application MAY provide
>       an NSLP payload (which will be used in any GIST-Response).
> 
>    o  to bypass the message and drop out of the signaling path.  The
>       application MAY provide an updated NSLP payload (which will be
>       used in the message which is then forwarded by GIST).

As the GIST API defines a "adjacency check" flag in RecvMessage, I suppose, 
GIST must indicate the request of a Messaging Association ("adjacency"?!?!) 
to the NSLP and the NSLP will then answer using a SendMessage with Transfer 
atributes accordingly set?

This raises some problems in my eyes:

- When late state setup is used,  GIST does not save any state where it later 
could check if a Message Association is rightly established (it will be 
established on receipt of a GIST Confirm). Only possibility would be to send 
no Stack Proposal in the Response. However, some local state must be 
established on Query receipt for asynchronously asking the NSLP via the 
API?!?!

- When a message association is to be set up, the GIST Querier does generally 
not include NSLP payload in the Query at all, because it gets queued until 
the Association is set up (NSLP could have required 'reliable' or 'secure' 
for the data). So GIST has no data to deliver to the NSLP when it asks if the 
association should be set up. It would in general only deliver "shall I 
associate", the MRI, the Session ID and the NSLPID...

Or is this section to be understood in a more general way? Is this "adjacency" 
simply about setting up routing state in general?

Even in this case, GIST would have no data payload if a Messaging Asociation 
is to be set up to deliver to the NSLP which then again has no information to 
decide about....however section 4.3.2 implies that NSLP payload could be 
essential for this decision.

Also, this procedure should be included in the state machine definitions, I 
think?

Cheers,
Thomas

---

From: Roland Bless <[email-masked]>
Date: Tue, 25 Oct 2005 16:34:00 +0200

Hi Thomas,

I think section 4.3.2 needs definitely some clarifications.

> GIST must indicate the request of a Messaging Association ("adjacency"?!?!) 
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
At least the terminology section doesn't state that Adjacency means or
is identical to an MA between two peers. IMHO it only defines that two
GIST nodes are directly adjacent with respect to GIST and NSLP.
If I understood the  Adjacency Check mechanism correctly it allows an
NSLP to act as a bypass if it is not interested in the exchange.

A little bit confusing is the fact that section 4.3.2 doesn't
specify exactly the message which may request the setup of an adjacency.
Is there a difference if it is a GIST-Query, GIST-Confirm, GIST-Response
or GIST-Data (maybe even received via an existing MA).

Again in more detail:
>>   adjacency MAY be required based on signaling application policy,

"an adjacency": is it an adjacency with the Querying upstream node?
Could it be a different adjacency with another third node?

>>      an NSLP payload (which will be used in any GIST-Response).

So an adjacency can only be setup by a GIST-Query? What is the
reaction of the local node? Does it send a GIST-Response back
in this case or why says the above sentence "_any_ GIST-Response"?

>>      used in the message which is then forwarded by GIST).

I assume that it should mean: the original message type with the updated
NSLP payload is forwarded further down the path, i.e. in this case no
GIST-Response is generated.

> established on Query receipt for asynchronously asking the NSLP via the 

So you mean some temporary local state until the NSLP has
given an answer and a corresponding GIST-Response
is created and sent back? This may be negligible because
you would need some resources for processing a Query anyway.
It is however important that no state is kept after the
Response is sent.

> associate", the MRI, the Session ID and the NSLPID...

This is related somewhat to the problem mentioned in the thread
"NSLP-Data in intial GIST-Query" and
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue74

> simply about setting up routing state in general?

I think it is not clearly defined in the draft what "setting up
an adjacency" really means...

Regards,
 Roland

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 26 Oct 2005 11:21:27 +0200

Hi,

comments are inline.

--On Freitag, 21. Oktober 2005 21:42 Uhr +0200 Roland Bless 
<[email-masked]> wrote:

| Hi Ali,
|
| (comments inline)
|
| Ali Fessi wrote:
|
|> Section: 4.2.6.1  The <Filters> Object
|>
|>    <Filters> restricts the set of considered flows for the metering.
|>    The MSPEC MUST support a value for <Filters> that is different from
|>    the flow information kept at GIST. In particular, <Filters> could be
|> for example, a 5-tuple where one or more fields are wild-carded.
|>
|>    For example, it MUST be possible to count all TCP SYN packets or all
|>    ICMP packets going to a given destination IP address.
|>
|> --------------
|
| The MF classifier definition from RFC 2475 is quite generic
| and could possibly be referenced here.
|
|> The reason is whether it makes sense to use NSIS for the configuration
|> of Metering Entities on the path from A to B to measure characteristics
|> of other flows than the ones going from A to B.
|
| That's an interesting question. On one hand this may be error prone,
| but see examples below.
|
|> I would like to ask you for your opinion on this topic:
|>
|> - do you think that the specification of the flows to be measured should
|> be restricted to the MRI from GIST.
|
|> -Or do you think it should be as flexible as possible?
|
| IMHO it would be good to be at least more flexible in the sense that
| you're interested in a subset of the aggregate that is defined
| by the MRI between A and B. For example, I think it is perfectly
| legitimate to measure or sample only certain TCP packets (as in your
| example above) or certain ICMP messages or even particular HTTP
| messages.
| So the MRI would match an aggregate flowing from A to B, and you're
| interested in a particular sub aggregate within. So the logic within
| the NSLP could check the semantics, i.e. whether the filter is
| actually picking a subset of the MRI.

I can second this. It is quite useful to extend the information by the MRI
on the NSLP level. The NATFW NSLP is doing something similar with the
extended flow information object and the data terminal object. Both
extend the MRI by limiting the flow spec.

|
| OTOH I can imagine a scenario where you are configuring
| filter for packets that are normally and currently *not*
| flowing on the path from A to B. So the filter would be
| used to detect/measure some failure conditions or anomalies. In this
| case it would be even useful to configure filters along
| A->B so that they match flows that are currently not routed
| along that path.

This would not be purely "path-coupled" anymore, since your are signaling
for flows apart your path.  Is see the only envisioned use case for this
filter spec in Section 4.3  "Monitoring for Network Security" of the M-NSLP
framework draft. However, I do not see the value of this use case and
therefore objecting the proposed semantics.

  Martin

---

From: Roland Bless <[email-masked]>
Date: Mon, 31 Oct 2005 13:14:06 +0100

Hi Martin,
> for flows apart your path.  Is see the only envisioned use case for this

Hmm, good question whether its path-coupled or not.
You are signaling for flows which might be on that particular path
in the future. Consider a domain with two ingress nodes A and B.
Current inter-domain routing will inject a flow aggregate F at ingress
A and route it to egress E. However, you might be interested when F is
actually flowing into ingress B taking a different path to E. However,
the current path will not lead to ingress B, and that's where it's not
exactly path coupled anymore.

> therefore objecting the proposed semantics.

I guess I have to read this draft and this section.
I'm not suggesting that this should be supported. Maybe
others have such requirements.

Regards,
 Roland

---

From: Ali Fessi <[email-masked]>
Date: Mon, 31 Oct 2005 13:32:51 +0100

Hi Roland and Martin,

> exactly path coupled anymore.

that's correct. On the path from A to E, you could detect packets that 
are not supposed to be routed on this path, either for security reasons, 
or for troubleshooting.

> I guess I have to read this draft and this section.

oh yeah! that would be great! :-) and feel free to send your comments 
about it! ;-)

> others have such requirements.

regards,
ali.