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

From: Ramin Alidousti <[email-masked]>
Date: Wed, 2 May 2001 13:55:32 -0400

Do you mean that I (as a customer) should trust my ISP and terminate
the IPsec on their edge and have them, again, establish another session
with the real endpoint? What if I'm running "super confidential" sessions
with another remote branch and I do not want anyone (including the ISP)
to see/analyse my traffic?

Although, I think that I must have missed the context of this reply.

Ramin

> 
> 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
> 
> 

_______________________________________________
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 14:16:23 -0400

i do not think sessions will be terminated at the isp, then reestablished to
the final endpoint.  i think jay is just saying that if one WERE to
terminate the session at the isp, then the isp could do diffserv because he
can crack the packet open.  i agree with you that this will probably not be
a likely scenario.

susie
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Ramin Alidousti
Sent: Wednesday, May 02, 2001 1:56 PM
To: Jay Wang
Cc: [email-masked]
Subject: RE: [Diffserv] questions regarding ipsec and diffserv

Ramin

_______________________________________________
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

---

From: Ramin Alidousti <[email-masked]>
Date: Wed, 2 May 2001 14:31:36 -0400

Oh, OK. Even if it were so, the first ISP along the path could
have done Diffserv processing, what about the other transit
ISP's carrying our traffic. Although, reclassification of the
packets is most likely attached to a SLA within one ISP's
backbone. Isn't it?

Ramin

-- 
Ramin Alidousti                                         [email-masked]
Advanced Development                             tel +1 703 886 2640
UUNET, A WorldCom Company                        fax +1 703 886 0536

---

From: "Susie Riley" <[email-masked]>
Date: Wed, 2 May 2001 14:53:37 -0400

i don't think we need to explore much further the implications of
terminating the session at the edge, only to reestablish it...  as i said
before, i think this will be a highly unlikely scenario.  the bottom line
is - once the session is encrypted by the originator, noone in between the
originator and the terminator can peek inside the packet to do 5-tuple
diffserv processing.

susie

-----Original Message-----
From: Ramin Alidousti [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 2:32 PM
To: Susie Riley
Cc: Ramin Alidousti; Jay Wang; [email-masked]
Subject: Re: [Diffserv] questions regarding ipsec and diffserv

Ramin

---

From: "Jay Wang" <[email-masked]>
Date: Wed, 2 May 2001 12:26:41 -0700

>before, i think this will be a highly unlikely scenario.

Oh, I am not so sure about this. Network based solutions, where the basic
idea is to outsource IP services (FW, NAT, VPN/Security, QoS, etc) to
the service provider, have gained lots of attention as of late. However,
one real issue shared by the vendors such as Cosine and Shasta regarding
security
is that the segment between the provider and their customer is vulnerable
in terms of security if the IPSec VPN starts at the provider's box. The
problem
is more significant, particularly, if the customer and the ISP edge is not
directly
connected by a private link. On the other hand, as I indicated, in order to
carry our the outsourcing model, the ISP edge often needs to look deep into
the customer's packets. To address this problem, one possible implementation
is to encrypt at the source and decrypt the edge, then provide the needed
packet
services, before encrypting it again.  Personally, I don't know for a fact
that
whether these vendors are doing this or not.  However, I am very certain if
you
talk to them, many would not consider this to be a 'highly unlikely'
scenario at all.

- jay

>the bottom line is - once the session is encrypted by the originator, noone
in between the

-----Original Message-----
From: Ramin Alidousti [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 2:32 PM
To: Susie Riley
Cc: Ramin Alidousti; Jay Wang; [email-masked]
Subject: Re: [Diffserv] questions regarding ipsec and diffserv

Ramin

---

From: demir <[email-masked]>
Date: Wed, 2 May 2001 12:39:01 -0700 (PDT)

There is a Security Parameter Index (SPI) in IPsec. It can be used in
place of the UDP/TCP-like ports between customer and provider. I don't
think that "ipsec and diffserv" is an issue (other than the ones explored
in the Diffserv related RFCs) in Diffserv.

Alper K. Demir

---

From: "Jay Wang" <[email-masked]>
Date: Wed, 2 May 2001 12:42:29 -0700

That is true.  However, the fundamental issues sustains in that
the MF (re-)classification may not stop at the 5-tuple. The SPI
has limited space for such encoding.

- jay

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

Alper K. Demir

On Wed, 2 May 2001, Susie Riley wrote:

> > i do not think sessions will be terminated at the isp, then
reestablished
> to

---

From: Fred Baker <[email-masked]>
Date: Wed, 02 May 2001 12:33:40 -0700

At 02:53 PM 5/2/2001 -0400, Susie Riley wrote:
>once the session is encrypted by the originator, noone in between the

no argument. Thus, it must be marked somewhere that someone can see the 
information, or the DSCP on the message must be trusted, or you lose 
considerable information. I'm not sure there are a lot of other options. 
There was at one point an IPSEC proposal to not obscure the port numbers in 
TCP and UDP; if you want to resurrect that and drive it, be my guest.

---

From: "Jay Wang" <[email-masked]>
Date: Wed, 2 May 2001 12:34:19 -0700

-----Original Message-----
From: Ramin Alidousti [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 10:56 AM
To: Jay Wang
Cc: [email-masked]
Subject: RE: [Diffserv] questions regarding ipsec and diffserv

>to see/analyse my traffic?

Then simply run the IPSec through the ISP's edge and only terminate it
at the final destination.  The two scenarios are not mutually exclusive at
all.

- jay

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 May 2001 14:39:32 -0500

Exactly. It only works if the downstream ISPs trust the DSCPs
they receive from upstream, and ISPs have always indicated
to us that they are unlikely to trust them.

Unless anyone has a brilliant idea, I think diffserv can
do little. If Susie is willing - a full problem statement would
be useful, and we (the diffserv chairs) can pass it on to
the IESG.

   Brian

---

From: "Susie Riley" <[email-masked]>
Date: Wed, 2 May 2001 16:10:39 -0400

jay,

yes, i am aware of the desire to offer outsourced ip services by the isps,
and yes, the path between the end user and the shasta box would be in the
clear and that does raise a security issue.  i think if a small business was
outsourcing vpn services from a isp, there might be 2 types of
configurations:
1. end users connected to isp (end user not running ipsec-vpn sw), isp doing
ipsec-vpn on behalf of end user to the vpn box/firewall at the central
office
2. end users connected to isp (end user not running ipsec-vpn sw), isp doing
ipsec-vpn on behalf of end user to the remote edge box at the isp (remote
edge box services the central office).

i believe situation 1 is not likely - since if the business has its own box
and it's managing its own VPN from its central office, then they will most
likely issue ipsec-vpn software (eg. checkpoint software) to the remote
users (win 2000 already has ipsec - dunno how it works with vpns though), so
there will be no need to buy vpn services from the isp for remote users.

in situation 2, where the business is not managing any of its vpn, and the
isp is doing it all for him, then the packet would be in the clear between
the user and the isp, then encrypted between the isp edge boxes, then in the
clear between the far edge box and the central office.  you make a good
point, in order to protect the 'clear' paths one could use ipsec.  however,
this does seem a little circular - doesn't this mean the end station and the
central office still have to be involved in vpn management and do ipsec and
so forth?  i don't know how much work this would save the central office in
the end.

seems like this discussion might be useful to have in the ppvpn group as
well.

susie

-----Original Message-----
From: Jay Wang [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 3:27 PM
To: Susie Riley; Ramin Alidousti
Cc: Jay Wang; [email-masked]
Subject: RE: [Diffserv] questions regarding ipsec and diffserv

- jay

in between the

-----Original Message-----
From: Ramin Alidousti [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 2:32 PM
To: Susie Riley
Cc: Ramin Alidousti; Jay Wang; [email-masked]
Subject: Re: [Diffserv] questions regarding ipsec and diffserv

Ramin

---

From: HungKei Keith Chow <[email-masked]>
Date: Wed, 2 May 2001 16:35:00 -0400 (EDT)

What "5-tuple diffserv" processing do you need within a diffserv domain? I
suppose none. When you cross DS domains, it will be up to your peering 
agreement (or SLA). It could just be a simple mapping, not necessary at
the micro-flow level.
--K

---

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

Jay,
Fundamental issue will sustain as long as IPsec is used and there is no
solution to that (so far I think). I gave the SPI to extend the space that
IPsec creates. Of course, its space is less that 5-tupple space.

Alper K. Demir

---

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

We don't need to invent it again. RFC2207 "RSVP Extensions for IPSEC Data
Flows" addresses the issue from RSVP/Intserv point of view and it has the
same problematic situation in Diffserv. 

Alper K. Demir

---

From: Ramin Alidousti <[email-masked]>
Date: Thu, 3 May 2001 08:48:02 -0400

In both cases described below the starting/termination point of
the vpn/ipsec will be on the customers' premises and not the ISP's
edge routers. In theory there is no 'clear' path on the public
IP network at all.

What you described below only holds as an administrative point
of view.

Ramin

---

From: "Susie Riley" <[email-masked]>
Date: Thu, 3 May 2001 09:15:46 -0400

in case 2 where the isp is providing vpn services without the use of cpe,
the data between the isp and the customers' premises is in the clear, unless
some kind of encryption is used.  the path between the isp and the customer
may traverse other networks (eg. cable or dsl provider's networks).  the
exposure here is that the data may not be protected while it is traversing
the 'other' networks between the isp and the end user/customer.

susie

-----Original Message-----
From: Ramin Alidousti [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 8:48 AM
To: Susie Riley
Cc: Jay Wang; Ramin Alidousti; [email-masked]
Subject: Re: [Diffserv] questions regarding ipsec and diffserv

Ramin

reestablished

---

From: Ramin Alidousti <[email-masked]>
Date: Thu, 3 May 2001 09:37:29 -0400

This would be a design flaw.

Ramin