[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ipsec] RE: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic
- To: <flefauch@xxxxxxxxx>
- Subject: [Ipsec] RE: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic
- From: Black_David@xxxxxxx
- Date: Mon, 2 Oct 2006 09:41:25 -0400
- Cc: ipsec@xxxxxxxx, tsvwg-chairs@xxxxxxxxxxxxxx, fred@xxxxxxxxx, saag@xxxxxxx, hartmans-ietf@xxxxxxx, Black_David@xxxxxxx
- In-reply-to: <F50E7731-E79D-4127-BDB5-DFBA82D0A1E8@xxxxxxxxx>
- List-help: <mailto:ipsec-request@ietf.org?subject=help>
- List-id: IP Security <ipsec.ietf.org>
- List-post: <mailto:ipsec@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
- Sender: owner-ietf-ipsec@xxxxxxxxxxxxx
- Thread-index: AcbmCozgS1x9wBpHT+iMb8LHSyJ9fgAHPd1w
- Thread-topic: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic
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