Subject: RE: [midcom] on "diversion"

From: Randy Turner <[email-masked]>
Date: Mon, 26 Mar 2001 00:42:41 -0800

Ok, I believe that's really what diversion means to me as well.

If this is out-of-scope, then this leaves out the ability to "outboard"
an ALG processor from the firewall/NAT device, which I guess is ok with me.

(I"m assuming that we're on the same page with the definition of an ALG ;)

Randy

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
Sent: Sunday, March 25, 2001 1:04 AM
To: Randy Turner
Cc: [email-masked]
Subject: Re: [midcom] on "diversion"

To me, diversion means the following (the numbers next to the lines
indicate the data flow):

    __________
   |          |
   | External |
   |  Host    |
   |__________|
       v
       |
       |
       |1
       |
       |
    ___v______     2        ______________
   |          |>---------->|              |
   |  NAT /   |            |  Application |
   | Firewall |<----------<|  Controller  |
   |__________|    3       |______________|
       v
       |
       |
       |4
       |
       |
    ___v______
   |          |
   | Internal |
   |  Host    |
   |__________|

Although I indicate flow direction from external to internal, the
opposite flow direction would also be considered a diversion.

Note that (3) is optional.  It's quite possible that the
application controller could conceivably consume the flow in its
entirety (like in the case of a transparent cache).

Requiring this sort of capability, and even mentioning it, is
a rathole.  I'm not arguing that we should go out of our way to
prevent it, but let's not go out of our way to do that either.

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: "Melinda Shore" <[email-masked]>
Date: Mon, 26 Mar 2001 07:55:38 -0500

> an ALG processor from the firewall/NAT device, which I guess is ok with me.

Actually, it doesn't - it just means that it wouldn't
be done in midcom.

Here's where I think we are with this:
1) a packet of "known" provenance or disposition arrives
on a middlebox and is diverted to some sort of application
or network proxy/ALG/auxiliary thing:  definitely out of
scope.

2) a packet of unknown provenance or disposition arrives
on a middlebox and we don't know what to do with it:
policy consultation to make a determination could be
part of the policy component, but diverting the packet
itself to some sort of application or network proxy/
ALG/auxiliary thing is definitely out of scope.

Melinda

---

From: "Abdallah Rayhan" <[email-masked]>
Date: Tue, 27 Mar 2001 13:53:13 -0500

Is diversion similar to the out-of-path concept? They seem to follow 
similar processing. 

regards
Abdallah