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

From: "Jay Wang" <[email-masked]>
Date: Tue, 1 May 2001 21:38:43 -0700

I think the IPSec scheme is OK for Diffserv even for
this scenario. This is the reasoning. If the ISP is allowed
to reclassify an encrypted packet based on the packet payload
at the provider's service edge, then it means the ISP is a trusted
party to the end user, where the IPsec session originates.  In this
case, the other endpoint for the end user's IPSec session really
should be the provider's edge. As a result, the edge shall be able
to decrypt the packet and do what it has to do, and put the
packet back to the stealth mode (e.g., by establishing another
IPSec session toward the destination). For all other intermediate
nodes, because packets encrypted are supposed to be secret
and they should be so. Therefore, we should not allow such
intermediate nodes to look deeper than they should since port
numbers do reveal a lot of information about the traffic. Otherwise,
it beats the purpose of the secrecy in the first place.

regards,

- Jay Wang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Brian E Carpenter
Sent: Monday, April 30, 2001 9:17 AM
To: Susie Riley
Cc: [email-masked]
Subject: Re: [Diffserv] questions regarding ipsec and diffserv

What you say is correct.

Actually there is nothing diffserv can do about it. It would need a change
to
IPSEC (to avoid encrypting the transport header). Somehow that doesn't seem
very likely.

   Brian

Susie Riley wrote:
>
> yes, i understand about the diffserv marking by the originating host, but
> devices at the edge may want to remark the packet because it wants to mark
> the packets based on its policies, instead of 'trusting' the end station.
>
> it seems the discussions in the rfcs are primarily relevant for tunnel
> terminating edge devices - the scenario i am talking about is the case of
a
> home PC, hooking up to a provider.  yes, the pc will have to do the
'right'
> marking, but the edge device at the provider may want to be able to verify
> or reclassify based on the 5-tuple.  i guess what it comes down to in this
> scenario is that provider edge devices will only be able to classify based
> on the top level ip header for ipsec packets, and there's no way to get
> around this limitation.  would you agree?  is this an issue the diffserv
> group is going to explore further?
>
> susie
>
> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 11:10 AM
> To: Susie Riley
> Cc: [email-masked]
> Subject: Re: [Diffserv] questions regarding ipsec and diffserv
>
> Interaction with IPSEC is discussed in several diffserv RFCs
> (2474, 2475 and 2983). RFC 2983 is the most relevant to your
> question.
>
> The problem you raise is real enough, and it's why diffserv marking
> by the originating host (i.e. before encryption) is a useful mechanism.
>
>    Brian Carpenter
>
> Susie Riley wrote:
> >
> > hi,
> >
> > i've been reading up on vpns and ipsec, and i've got a question for the
> > diffserv group - if someone could shed some light in this matter i would
> > really appreciate it.
> >
> > once a packet is encrypted according to ipsec, the tcp header is no
longer
> > visible to any edge router that is trying to perform the diffserv
> function.
> > this means the diffserv classifier can only examine the ip header for
> > encrypted packets.  is this considered to be an issue for diffserv?
will
> > not the proliferation of ipsec on PCs (soon ipsec will become standard
> issue
> > on microsoft os)and PKI mean that eventually a large number of sessions
> over
> > the internet will be encrypted, thus challenging the usefulness of
> > diffserv's 5-tuple approach?
> >
> > thanks in advance,
> > susie
> >
> > ******************************
> > Susie Kim Riley              *
> > Senior Consulting Engineer   *
> > ADCT                         *
> > Tel: 508-898-8840            *
> > ******************************

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

_______________________________________________
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: "Susie Riley" <[email-masked]>
Date: Wed, 2 May 2001 08:39:44 -0400

i think in most instances the user's session will be encrypted until it gets
to its final destination (or vpn firewall) - i don't see a purpose to
terminating the session at the isp, then to reencrypt it, from the user's
point of view.  yes, from the isp's point of view, that would be nice
because then the isp has full visibility into the packet.

my point was - since the isp can't look at the packet anyway (beyond layer
3), it seems to compromise some of the objectives of diffserv.  brian had
made a point in a private exchange that since ipsec doesn't play well with
NAT, ipsec may not see wide deployment until ipv6.  he's got a good point.
this may buy us some time, but once ipv6 comes out, then what?  seems like
maybe we could do some work ahead (possibly with the ipsec group) to address
some of these issues up front before we 'collide'.

susie

-----Original Message-----
From: Jay Wang [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 12:39 AM
To: Brian E Carpenter; Susie Riley
Cc: [email-masked]
Subject: RE: [Diffserv] questions regarding ipsec and diffserv

regards,

- Jay Wang

-----Original Message-----

What you say is correct.

   Brian

a
'right'
longer
will

---

From: demir <[email-masked]>
Date: Wed, 2 May 2001 13:35:32 -0700 (PDT)

> some of these issues up front before we 'collide'.

I don't think there is any restriction at the edge of ISP on upto layer 
3. Edge can go beyond layer 3. It is only in the core.

Alper K. Demir