Subject: [Ipsec] RE: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic

From: [email-masked]
Date: Thu, 28 Dec 2006 16:44:41 -0500

Francois,

My general concern for the draft is:

> > The concern about how to use a PHB consisting of multiple DSCPs
(e.g., AF)
> > also applies to the rsvp-ipsec draft.  Using PHBIDs (cf. RFC 3140)
may
> > help address this, and this concern may also affect RFC 3175.

For example, this sentence from the Introduction (Section 1) applies
to EF, but not AF for carrying the reserved traffic:

   One example is where E2E reservations using 
   different preemption priorities (as per [RSVP-PREEMP]) need to be 
   aggregated through a Diffserv cloud using the same DSCP.

The underlying situation is that the raw notion of DSCP is being used
instead of a PHB, and for better or worse, this is already the case
in RFC 3175.  The practical upshot is that RFC 3175 effectively forbids
use of AF PHBs for carrying reserved traffic - one has to explicitly
specify the DSCP (which could also be used as part of an AF PHB if
one was being careful).  Going back and changing RFC 3175 at this
point is definitely *not* a good idea, so I would suggest just making
this observation (RFC 3175 requires use of a single DSCP for traffic
aggregated into a single reservation) in the rsvp-ipsec draft and
observing that this forbids meaningful use of AF drop precedence
for traffic covered by an RSVP reservation.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
> Sent: Tuesday, December 26, 2006 6:04 AM
> To: Black, David
> Cc: Francois Le Faucheur IMAP; Sam Hartman; [email-masked]; 
> [email-masked]; [email-masked]; Fred Baker; Bose Pratik
> Subject: Re: [saag] tsvwg,preemption and rsvp: exposing 
> characteristics of confidentialtraffic
> 
> Hello David,
> 
> Now that we've converged on the list on the text for the Security  
> Considerations section, I'd like to issue the updated version of the  
> Generic Aggregate RSVP Reservation I-D (i.e. the confusingly named  
> rsvp-ipsec draft).
> 
> My understanding is that Fred/Pratik will do some edits in vpn- 
> signaled-preemption as discussed by email to address your initial
concern.
> Is there anything remaining from your concern below that you feel  
> still needs resolution in rsvp-ipsec?
> If yes, any specific suggestions?
> 
> Thank you and happy holiday season.
> 
> Francois
> 
> On 2 Oct 2006, at 15:41, [email-masked] wrote:
> 
> > Francois,
> >
> > The concern about how to use a PHB consisting of multiple DSCPs
(e.g., AF)
> > also applies to the rsvp-ipsec draft.  Using PHBIDs (cf. RFC 3140)
may
> > help address this, and this concern may also affect RFC 3175.
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> >> -----Original Message-----
> >> From: Francois Le Faucheur [mailto:[email-masked]]
> >> Sent: Monday, October 02, 2006 6:03 AM
> >> To: Black, David
> >> Cc: Francois Le Faucheur; [email-masked];
> >> [email-masked]; [email-masked]; [email-masked];
> >> [email-masked]
> >> Subject: Re: [saag] tsvwg,preemption and rsvp: exposing
> >> characteristics of confidentialtraffic
> >>
> >> Hello,
> >>
> >> Just expanding on Dave's observation:
> >>
> >>>> These drafts set up a model under which each precedence class of
data
> >>>> from a preemption standpoint goes over its own SA and uses its
own
> >>>> aggregate RSVP reservation.  What that means is you expose on the
> >>>> unprotected side of the interface what fraction of your traffic
is at
> >>>> each precedence level.
> >>>
> >>> Actually, only the vpn-signaled-preemption draft appears to do
this.
> >>>
> >>> The rsvp-ipsec draft allows multiple reservations between the same
> >>> endpoints for the same DSCP, which would allow such traffic to use
> >>> different tunnels but if it requires traffic for different
> >>> reservations to use different tunnels, I was not able to find
> >>> a statement of that requirement.
> >>>
> >>
> >> Right.
> >> The rsvp-ipsec draft effectively decorelates the aggregate
> >> reservations from the security associations (this was done as a
> >> result of the first round of Security Experts review we got). So,
for example,:
> >> 	* it allows to set up multiple aggregate reservations using a
single SA
> >> 	* it allows to setup one aggregate reservation per SA
> >> 	* it does not force/mandate either of these modes.
> >>
> >> The logic is to provide a generic mechanism which may be used in
> >> different ways, in particular in the way(s) discussed in
vpn-signaled-preemption.
> >> rsvp-ipsec refers to vpn-signaled-preemption's Security
> >> Considerations for when used as per vpn-signaled-preemption.
> >>
> >> Cheers
> >>
> >> Francois
> 
> 

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

---

From: [email-masked]
Date: Fri, 29 Dec 2006 13:00:36 -0500

Francois,
 
> Do you agree that RFC 3175 allows use of AF?
 
Yes - the fact that it deliberately did not put in a full PHB-ID is
unfortunate,
as having to infer from context whether a DSCP is a singleton vs.
representative
of a group from context is not the best approach.  It looks like I
missed
this AF support in quickly scanning RFC 3175.
 
> With respect to rsvp-ipsec, a simple approach is to edit the
description text of the "DSCP" field in the
> GENERIC-AGGREGATE SESSION object along the lines of what is in RFC
3175 (ie if session uses
> single PHB, then field contains the DSCP of PHB. If session uses group
of PHBs like AF1x, then field
> contains the numerically smallest DSCP value as per [PHB-ID]). This
would make it explicit that
> rsvp-ipsec also allows use of PHB groups, and would ensure consistent
use of DSCP field between
> RFC 3175 and rsvp-ipsec.
 
That's probably the right thing to do at this juncture, because ...
 
> The other approach would be to change the format of the
GENERIC-AGGREGATE SESSION object
> and include a full 16-bit PHB-ID instead of DSCP field. I can see that
this could help in situations where
> (i) the Aggregate reservation crosses Diffserv domain boundaries and
(ii) different DSCP values are used
> for a given PHB/PHB-group. But I am not sure that this would be a
common situation. On the flip side,
> it would make things less consistent between RFC 3175 and rsvp-ipsec
(for example, in cases where the
> operator has elected to use a DSCP for the PHB which is different from
the recommended DSCP value,
> then RFC 3175 would encode the used-DSCP while rsvp-ipsec would encode
the recommended-DSCP
> as per PHB-ID).
 
... probably entails going back and changing RFC 3175 to use a PHB-ID,
something
that it's probably entirely too late to do, and I agree that a
divergence between
RFC 3175 and rsvp-ipsec is undesirable.
 
> BTW: One related question on PHB-ID. PHB-ID says " Note that the
recommended DSCP value MUST
> be used, even if the network in question has chosen a different
mapping." So what happens if someone wants
> to deploy two instances of EF? how do you encode those in a PHB-ID?
 
The second EF instance would be a case 2 PHB-ID - experimental or local
use.
The current PHB-ID reference is RFC 3140.
 
One of the things I think we're discovering (e.g., w/Fred's
admitted-voice PHB)
is that EF instances aren't completely combinable in practice - in
theory they're
completely combinable, and hence one never needs more than one, *if* the
rules
are followed perfectly.  That "if" doesn't appear to completely hold in
practice.
 
Thanks,
--David

________________________________

	From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
	Sent: Friday, December 29, 2006 5:01 AM
	To: Black, David
	Cc: Francois Le Faucheur IMAP; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
	Subject: Re: [saag] tsvwg,preemption and rsvp: exposing
characteristics of confidentialtraffic

	Hello David,

	Now I understand your concern. Please see below:

	On 28 Dec 2006, at 22:44, [email-masked] wrote:

		Francois,

				The concern about how to use a PHB
consisting of multiple DSCPs

		(e.g., AF)

				also applies to the rsvp-ipsec draft.
Using PHBIDs (cf. RFC 3140)

		may

				help address this, and this concern may
also affect RFC 3175.

		For example, this sentence from the Introduction
(Section 1) applies
		to EF, but not AF for carrying the reserved traffic:

		   One example is where E2E reservations using 
		   different preemption priorities (as per
[RSVP-PREEMP]) need to be 
		   aggregated through a Diffserv cloud using the same
DSCP.

		The underlying situation is that the raw notion of DSCP
is being used
		instead of a PHB, and for better or worse, this is
already the case
		in RFC 3175.  The practical upshot is that RFC 3175
effectively forbids
		use of AF PHBs for carrying reserved traffic - 

	Actually, RFC 3175 explicitly (attempts to) allow(s) the use of
AF PHBs for carrying reserved traffic.
	In particular, it says:
	"
	   In the case where a session uses a pair of PHBs (e.g., AF11
	   and AF12), the DSCP used should represent the numerically
smallest
	   PHB (e.g., AF11).  This follows the same naming convention
described
	   in [BRIM].
	...

	   [BRIM]       Brim, S., Carpenter, B. and F. LeFaucheur, "Per
Hop
	                Behavior Identification Codes", RFC 2836, May
2000.
	"

	Do you agree that RFC 3175 allows use of AF?

		one has to explicitly
		specify the DSCP (which could also be used as part of an
AF PHB if
		one was being careful).  Going back and changing RFC
3175 at this
		point is definitely *not* a good idea, so I would
suggest just making
		this observation (RFC 3175 requires use of a single DSCP
for traffic
		aggregated into a single reservation) in the rsvp-ipsec
draft and
		observing that this forbids meaningful use of AF drop
precedence
		for traffic covered by an RSVP reservation.

	With respect to rsvp-ipsec, a simple approach is to edit the
description text of the "DSCP" field in the GENERIC-AGGREGATE SESSION
object along the lines of what is in RFC 3175 (ie if session uses single
PHB, then field contains the DSCP of PHB. If session uses group of PHBs
like AF1x, then field contains the numerically smallest DSCP value as
per [PHB-ID]). This would make it explicit that rsvp-ipsec also allows
use of PHB groups, and would ensure consistent use of DSCP field between
RFC 3175 and rsvp-ipsec.

	The other approach would be to change the format of the
GENERIC-AGGREGATE SESSION object and include a full 16-bit PHB-ID
instead of DSCP field. I can see that this could help in situations
where (i) the Aggregate reservation crosses Diffserv domain boundaries
and (ii) different DSCP values are used for a given PHB/PHB-group. But I
am not sure that this would be a common situation. On the flip side, it
would make things less consistent between RFC 3175 and rsvp-ipsec (for
example, in cases where the operator has elected to use a DSCP for the
PHB which is different from the recommended DSCP value, then RFC 3175
would encode the used-DSCP while rsvp-ipsec would encode the
recommended-DSCP as per PHB-ID).

	Thoughts?

	BTW: One related question on PHB-ID. PHB-ID says " Note that the
recommended DSCP value MUST be used, even if the network in question has
chosen a different mapping." So what happens if someone wants to deploy
two instances of EF? how do you encode those in a PHB-ID?

	Cheers

	Francois

		Thanks,
		--David