Subject: RE: [Diffserv] questions regarding ipsec and diffserv

From: "Greene, Jeremy" <[email-masked]>
Date: Wed, 2 May 2001 18:24:20 -0400

This is interesting...

On one hand I don't see why an ISP would ever want to classify on anything
other than the DSCP. Isn't that the real goal of DS?

It's the originator (either the customer's end-system or the customer's edge
router) that does the MF classification which eventually results in marking
the packet with a DSCP. In either case, it's nice not to have any part of
the packet encrypted when using a MF classifier :) But if the isp is only
doing BA classification, then it doesn't matter if the packet is encrypted.

But if the isp does want to do MF classification (highly managed service),
it's not clear that just seeing the header buys much of anything because: 1)
it may not be enough (app classification) and 2) the header itself can be
modified producing the incorrect dscp.

Same basic point for DSCP tampering -- doesn't seem like a DS issue, but the
fact that anything in the un-encrypted header, which is used by the isp to
forward a packet, can be tampered with.

Jeremy

> -----Original Message-----
> From: demir [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 5:32 PM
> To: Greene, Jeremy
> Cc: 'Brian E Carpenter'; Fred Baker; Susie Riley; [email-masked]
> Subject: RE: [Diffserv] questions regarding ipsec and diffserv
> 
> 
> I fail to see the higher level difference between one-ISP and multiple
> ISPs. The whole depend on the "trust-issue". If I "trust" my 
...

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: demir <[email-masked]>
Date: Wed, 2 May 2001 15:53:07 -0700 (PDT)

> other than the DSCP. Isn't that the real goal of DS?

In the "core" yes, at the "edge" no, I think, because the way Diffserv is
defined. 

> doing BA classification, then it doesn't matter if the packet is encrypted.

If all customers are at the "stub" diffserv domains and/or
"downstream" diffserv domains are not responsible for MF classification at
all, then you are right, I think. I don't think Diffserv has any
restriction on this.

> forward a packet, can be tampered with.

I see this as the weakness of Diffserv. I don't see any relevance to
discussion :)

Alper K. Demir

---

From: Fred Baker <[email-masked]>
Date: Wed, 02 May 2001 16:45:31 -0700

>In the "core" yes, at the "edge" no, I think, because the way Diffserv is

incorrect. The reason MF classification is talked about is that (prepare to 
be shocked) there exist systems in the world that do not pre-classify their 
traffic with DSCPs. Therefore, someone has to be prepared to change the 
DSCP based on other packet attributes. However, if a packet is properly 
classified in the host (if, for example, voice is marked EF), there is no 
substantive reason to change it anywhere.

---

From: demir <[email-masked]>
Date: Wed, 2 May 2001 17:42:33 -0700 (PDT)

Fred,
> traffic with DSCPs. Therefore, someone has to be prepared to change the 

I don't see any reason why my claim is incorrect. It might be incomplete,
but it is enough to make the point.

> substantive reason to change it anywhere.

I agree there is no substantive reason to change it anywhere. What is the
purpose of "policing" in Diffserv? I assume because of "trust" issue.

Alper K. Demir

---

From: Fred Baker <[email-masked]>
Date: Wed, 02 May 2001 18:22:42 -0700

At 05:42 PM 5/2/2001 -0700, demir wrote:
>What is the purpose of "policing" in Diffserv? I assume because of "trust" 
>issue.

yes. policing does not necessarily require changing a code-point, nor does 
it require 5-tuples. I am responding to your statement that edge devices 
had to do MF classification, while core devices do DSCP classification. 
edge devices can do either as happens to be appropriate.

---

From: demir <[email-masked]>
Date: Wed, 2 May 2001 18:40:15 -0700 (PDT)

Fred,
I think we are talking about the same thing because I agree with your
points, truly. 

> it require 5-tuples. I am responding to your statement that edge devices 

I didn't say that it is obligatory (5-tupple classification). It is
optional. That's one of the reasons that IPsec is problematic. I don't
think that issue here is changing a code point.

> edge devices can do either as happens to be appropriate.

I assume there is a misinterpretation. Could you please point me out if I
mis-typed such things. Thank you very much.

Alper K. Demir

---

From: Mahadevan Iyer <[email-masked]>
Date: Thu, 03 May 2001 01:18:21 -0700

> edge devices can do either as happens to be appropriate.

And even core devices may do more things than the compulsory DSCP classification. For this
purpose, core devices may want extra packet information (over and above the ip header) too.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 May 2001 08:57:37 -0500

> substantive reason to change it anywhere.

Only if all ISPs agree on the same DSCP to PHB mapping, which some ISPs
insisted be flexible. At the minimum, that requires DSCP rewriting.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 May 2001 09:05:15 -0500

The model carefully does not require anything but BA classification in
core nodes, to guarantee scaleability. Think about photonic devices.

This discussion isn't advancing the WG any more. I suggest that if people
want to continue, they take it over to the diffserv-interest list.

   Brian

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 03 May 2001 10:48:07 -0700

"Greene, Jeremy" wrote:
...
> modified producing the incorrect dscp.
...
I feel compelled to weigh in here on a nit. Something that seems
to be a continuing them is an assumption that an MF classifier is
a 5-tuple classifier. This is just not true. I initially used that
term in the "strawman" diffserv draft that was superseded by drafts
that became RFC2474 & 2475 and the original notion was preserved in
the definition in RFC 2475:

 MF Classifier             a multi-field (MF) classifier which selects
                             packets based on the content of some
                             arbitrary number of header fields;
                             typically some combination of source
                             address, destination address, DS field,
                             protocol ID, source port and destination
                             port.

Notice that this says "typically" and then lists *six* fields.

So saying an MF classifier "may not be enough" just means you have the
wrong MF classifier.

	nit-picking (but this stuff tends to work its way into the
		common consciousness since it's more fun to read
		email than RFCs),

		Kathie

---

From: demir <[email-masked]>
Date: Thu, 3 May 2001 12:09:39 -0700 (PDT)

Security Parameter Index (SPI) in IPsec can carry field/fields
(combination, partial, etc) of layer 4 and/or higher layers such as
UDP/TCP-like ports when IPsec is used and and MF classifers can classify
these flows wherever/whenever it is required. These solution can give some
sort of flexibility, but, of course, the scope of the individual flows is
not as large as the scope of individual flows where IPsec is not. If the
middle points have capability of encyrpting/decrypting then it is another
story. 

Alper K. Demir