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

[Black_David@xxxxxxx]

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
black_david@xxxxxxx        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Francois Le Faucheur IMAP [mailto:flefauch@xxxxxxxxx] 
> Sent: Tuesday, December 26, 2006 6:04 AM
> To: Black, David
> Cc: Francois Le Faucheur IMAP; Sam Hartman; saag@xxxxxxx; 
> ipsec@xxxxxxxx; tsvwg-chairs@xxxxxxxxxxxxxx; 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, Black_David@xxxxxxx 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
> > black_david@xxxxxxx        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> >> -----Original Message-----
> >> From: Francois Le Faucheur [mailto:flefauch@xxxxxxxxx]
> >> Sent: Monday, October 02, 2006 6:03 AM
> >> To: Black, David
> >> Cc: Francois Le Faucheur; hartmans-ietf@xxxxxxx;
> >> saag@xxxxxxx; ipsec@xxxxxxxx; tsvwg-chairs@xxxxxxxxxxxxxx;
> >> fred@xxxxxxxxx
> >> 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
Ipsec@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ipsec