Subject: Middlebox Features

From: Patrik Fältström <[email-masked]>
Date: Thu, 7 Sep 2000 21:19:56 +0200

The IESG is worried about "middlebox features" which comes up all 
over the place. Just all over. The way people think about early TCP 
termination, "front-ending SSL connections so the SSL is not all the 
way to the server", ...etc might not all the time work well in todays 
design of the Internet.

Is this trend driven by customers to companies asking for features 
without knowing what they are asking for? Because, companies only 
make products which customers buy, right? ;-)

We ask if not the WREC wg is the closest group we have on looking 
into these issues, and hope that the WREC wg will try to design 
functionality which is needed without jumping through too many loops 
and bending themselves backwards, violating the ground principles of 
end-to-end-communication which the IESG and IAB belive is needed for 
fundamental architectual things to work (like IPSEC etc).

One document we have found is draft-tomlinson-epsfw-00.txt, which we 
think is interesting because it is discussing some of these issues 
(yes, I know it was on the agenda at the last IETF... :-)

Can you please in the work you do on rechartering think about these 
"middleware feature" thing, and whether you should not include some 
wording about that in your charter? We also would like you to have a 
look at draft-tomlinson-epsfw-00.txt and deside if you should have 
that document as part of what you work items (so it gets proper 
review at least)?

    Regards, Patrik
    Area Director, Applications Area

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 08 Sep 2000 23:27:09 +0200

> way to the server", ...etc might not all the time work well in todays

I think most IP people dislike the TCP hacks quite often done today in
load balancers and "transparent" proxies & accelerators. This is bound
to give problems sooner or later (quite often sooner in my experience).

Regarding the SSL connection termination outside the "web server" I
don't view it as a problem if done properly (i.e. no TCP hacking).
Technically what is done is to introduce a HTTPS->HTTP application
gateway in the request flow. The end point the user client connects to
is the gateway application.

--
Henrik Nordström

---

From: "Douglas Gourlay" <[email-masked]>
Date: Fri, 8 Sep 2000 14:37:22 -0700

I have to agree with this logic.  SSL termination devices placed in front of
web servers for the purpose of offloading the computationally expensive key
generation/exchange and/or the encryption/decryption processing are not much
more than hardware optimized web proxy servers.  The key design
considerations this generates are more in the security space.  I say this
because how we choose to deal with this "used to be encrypted" data after
termination is a concern that will plague the end-user of a commerce site.

dg

------------------------------------------
Douglas Gourlay
W- 415.371.2345
C- 415.269.3684

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 08, 2000 2:27 PM
To: Patrik Fältström
Cc: [email-masked]
Subject: Re: Middlebox Features

--
Henrik Nordström

---

From: John Stracke <[email-masked]>
Date: Fri, 08 Sep 2000 17:44:59 -0400

Douglas Gourlay wrote:

> The key design

Yes, but we have similar concerns today, because the transaction records are
normally stored in plaintext.  For most commerce sites, it's probably easier to
break into the database than to intercept network traffic (more lucrative, too,
since you can get more data in a short time).

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |"What we have here is a failure to assimilate."|
[email-masked]|--Cool Hand Locutius                           |
\================================================================/

---

From: "Douglas Gourlay" <[email-masked]>
Date: Fri, 8 Sep 2000 15:02:42 -0700

I absolutely agree.  A database hack can be MUCH more valuable than just
traffic interception.  Some large financial institutions I have worked with
on this have been more concerned about the "ease" of the hack for an insider
though.  For instance,  it takes some degree of skill to hack the DB and
pull down all the CC numbers.  On the other hand, the skill level required
to put a sniffer between two nodes and capture packets is far less.
Although it does imply a trust issue (employee-employer) is gone and
physical security at the site has been violated.

So fundamentally I think we are in agreement that SSL termination is not a
"bad" thing provided the designs  they are deployed within conform to a
reasonable level of security.

dg

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Friday, September 08, 2000 2:45 PM
To: [email-masked]
Subject: Re: Middlebox Features

Yes, but we have similar concerns today, because the transaction records are
normally stored in plaintext.  For most commerce sites, it's probably easier
to
break into the database than to intercept network traffic (more lucrative,
too,
since you can get more data in a short time).

---

From: John Stracke <[email-masked]>
Date: Fri, 08 Sep 2000 18:13:00 -0400

Douglas Gourlay wrote:

> On the other hand, the skill level required

True, but how many sites encrypt the link between the Web server and the DB? It
might take a bit more skill than sniffing the HTTP, because the database
protocol is probably harder to read than HTTP, but probably not a lot more.

Really, an SSL connection only assures the user that nobody can intercept their
traffic out on the public Internet.  Once that's understood, the
SSL-terminating boxen sound more reasonable.

Um...however, there is one way they could make matters much worse.  I can
imagine a shady (or really ignorant) company offering SSL termination services,
where the unencrypted hop runs over the public Internet.  It'd be even more
vulnerable than a completely unencrypted setup, because all the unencrypted
data would be running over more or less the same path, so it'd be easier to
intercept.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"If there's anything The Flintstones have taught|
[email-masked]|us, it's that pelicans can be used to mix       |
|                |cement." -- Homer Simpson                       |
\=================================================================/

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 09 Sep 2000 00:20:44 +0200

Douglas Gourlay wrote:

> The key design considerations this generates are more in the
> security space.  I say this because how we choose to deal with
> this "used to be encrypted" data after termination is a concern
> that will plague the end-user of a commerce site.

Sure, and this does not have that much with SSL to do. More of a general
concern how sensitive data is processed at the site. The reasoning must
be applied to the whole chain where the data is processed, not only the
web server.

SSL acceleration gateways are part of the service setup, just as HTTP
servers, server-side applications, SQL servers and even humans
processing the entered data. Where you draw the line on how far data
must be encryped depends on the requirements of setup as a whole, not a
single component like SSL.

--
Henrik Nordstrom

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Sep 2000 09:27:17 -0700

> to give problems sooner or later (quite often sooner in my experience).

To be more specific, IP people avoid violating existing standards (TCP,
IP), both because of potential side effects, as well as it 'robs Peter
to pay Paul'. Either standards matter (in which case don't violate the
old one), or they don't (in which case why bother creating the new one).

It is the hack which is liable to give problems sooner or later; not the
IP people's dislike of them.

:-)

Joe