Subject: Michael Richardson: middle boxes vs security

From: [email-masked] (Michael Richardson)
Date: Thu, 22 Mar 2001 13:21:12 -0500

To: [email-masked]
Subject: middle boxes vs security
In-reply-to: Your message of "Wed, 21 Mar 2001 10:52:27 EST."
             <[email-masked]> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 22 Mar 2001 03:30:14 -0500
From: Michael Richardson <[email-masked]>

  It is interesting that the inability to deploy security due to presence of
middle boxes, such as security gateways, has prevented deployment of voice
services.
  (Frankly, I think that the overly complicated H.323 that has been the
culprit for years... H.323 was designed without reference to security
gateways at all, but perhaps this is simply a good example of the problem)a

  I would invite people to take a look at the SPP drafts that are part of the
IPsec Security Policy WG as background for a new protocol.

  In this case, the SPP attempts to discovery security gateways along the
forwarding path, determine appropriate security policies for traversing them, 
and resolve conflicts in the policies. With the config model, MIB and PIB
going to last call now, IPSP expects to make progress now on a new security
gateway/policy discovery protocol.

] Train travel features AC outlets with no take-off restrictions|gigabit is no[
]   Michael Richardson, Solidum Systems   Oh where, oh where has|problem  with[
]     [email-masked]   www.solidum.com   the little fishy gone?|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: [email-masked] (Herve Schauer)
Date: Fri, 23 Mar 2001 17:10:06 +0100 (CET)

>middle boxes, such as security gateways, has prevented deployment of voice

     I do not understand.

     In draft-lear-middlebox-arch-01.txt, a middle box can be a NAT box or a
 firewall. I think this is a mistake to think you can caracterize some
 network devices as middle boxes this way, and others network devices
 not being middle boxes.
     Any switch-router is always able to do NAT, and always have firewalling
 capabilities like IP filtering. In most case the usage of IP access-lists
 if not only for access-control, but also routing, QoS, VLANs, etc.
     So, in the real world, all IP network devices are middle boxes with
 such a definition. I think we should reserve middle box definition for
 boxes working at the application layer like boxes between WAP and HTTP.

     What is you definition of the middle box ?

     Why security gateways (id a network device building IPsec tunnels)
 has prevented deployment of voice services ?

     Regards,

         HERVE

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Mar 2001 12:48:53 -0500

>>>>> "Herve" == Herve Schauer <[email-masked]> writes:

    >> middle boxes, such as security gateways, has prevented deployment of voice

    Herve>      I do not understand.

    Herve>      In draft-lear-middlebox-arch-01.txt, a middle box can be a NAT box or a
    Herve>  firewall. I think this is a mistake to think you can caracterize some
    Herve>  network devices as middle boxes this way, and others network devices
    Herve>  not being middle boxes.

  I said "security gateway", not middle box --- that doesn't mean just VPN
box. I means firewall as well.

---

From: "Abdallah Rayhan" <[email-masked]>
Date: Fri, 23 Mar 2001 10:30:00 -0500

Michael,

You make a good point. It is one of the reasons why we are pushing 
to decouple distribution of IPsec policies from the discovery
issues as each serves a different purpose. The discovery issue
applies to several problems like the one you mentioned while the
policy is focused on things related to IPSec. I admit that there 
is an advantage of coupling the two but far more advantages in the
decoupled approach. 
 
my 2 cents

regards
Abdallah