Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 20 Jun 2001 07:54:35 -0600

In the interest of finding more acceptable terms for what these
middleboxes are doing, how about:

  "stealth" 

...as in "stealthy packet forwarding" done by ALG and NAT middleboxes
(who don't always route in the traditional sense). The term "transparent
routing" below isn't at all clear: It can be argued that routing does
not always occur at a NAT device.

And the idea of "end-to-end transparency" is debatable. If anything,
ALG+NAT provides a degree of transparency and typically compatibility
across IP realms. So maybe we want to be talking more about what's
actually going on here: 

  "IP address realm traversal"

which is what the NAT box is doing at a low level and the ALG is doing
at the application protocol level. 

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Pyda Srisuresh [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 2:12 PM
To: Brian E Carpenter; Zmolek, Andrew (Andrew)
Cc: Melinda Shore; Pyda Srisuresh; Fleischman, Eric W; Andrew Molitor;
[email-masked]
Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02

I did a grep on the terms "Transparent" and "transparency" to see 
where and how they are used in the FW document. Below is a list of 
my findings and sugegsted remedies.

I believe, it is OK to use terms like "end-to-end transparency" (item 1
below) and "Transparent routing" (item 3 below). They have a specific 
meaning that goes with them.

But, as Brian pointed out, it is tricky to use these temrs in the 
context of proxies, ALGs, agents and the like.

1. Paragraph 1 of section 1 - Introduction

   "Application Level gateways (ALGs) are used in conjunction with NAT
    to provide end-to-end transparency for many of the applications."

   I think, it should be OK to leave this unchanged.

2. Paragraph 3 of Section 1 - Introduction

   "The communication between a MIDCOM agent and a middlebox will be
    transparent to the end-hosts that take part in the application,
    unless one of the end-hosts assumes the role of a MIDCOM agent."
 
   I could reword this as follows:

   "The communication between a MIDCOM agent and a middlebox will
    not be noticeable to the end-hosts that take part in the
application,
    unless one of the end-hosts assumes the role of a MIDCOM agent."

3. Sectin 2.4. - NAT

   "Network Address Translation is a method by which IP addresses are
    mapped from one address realm to another, providing transparent
    routing to end-hosts."

   This definition is settled after a long series of discussion 
   prior to advancing RFC 2663. The definition is carried as is 
   from RFC 2663. I donot recommend changing this.
 
4. Paragraph 3 of section 2.6 - ALG

   "ALGs are different from proxies. ALGs are transparent to 
   end-hosts, unlike the proxies which are relay agents terminating
   sessions with both end-hosts."

   I could rephrase the above as follows:

   "ALGs are different from proxies. ALGs are not visible to 
   end-hosts, unlike the proxies which are relay agents terminating
   sessions with both end-hosts."

5. Paragraph 3 of section 5.2. - OOP MIDCOM agents

   "In essence, a middlebox provides to an Out-of-Path MIDCOM agent
    the ability to transparently "snoop" and modify the control
    traffic."

   I can reword the above as follows.

   "In essence, a middlebox provides to an Out-of-Path MIDCOM agent
    the same priveleges as that of an In-Path agent, to application
    control traffic, to "snoop" and modify as deemed appropriate."

6. The legend in figure 5 for "Ctrl" is described as follows.
   "Ctrl - indicates the FTP control traffic, which
           is transparently diverted to the OOP agent (2 and 3)"

   I can remove the word, and yet not change the semantics here. 

Thanks. 

regards,
suresh

--- Brian E Carpenter <[email-masked]> wrote:
> I think the word "transparent" has too many interpretations
> and too much history of abuse (as in "transparent proxy") to be a
> useful word in this context. I think we should simply not use
> the words "transparent" or "transparency" at all.
> 
>   Brian
> 
> > "Zmolek, Andrew (Andrew)" wrote:
> > 
> > It seems that we've been debating the meaning of transparency for
some time
> now. Perhaps we are talking about different shades
> > of transparency, and if that really does matter than we need to
elaborate.
> > 
> > - Transparency at an application layer so that client and server
both have
> a rational conversation is probably what we're
> > aiming for when we talk about OOP agent transparency. Some OOP
agents still
> manage to mangle things here, but the aim is still
> > transparency.
> > 
> > - Transparency at the transport layer is something else. Many OOP
agents
> will have to interact with the underlying transport
> > infrastructure to deal with packet forwarding, route information,
address
> and port assignment details, etc. So transparency is
> > a harder sell here.
> > 
> > Is it possible we can find enough middle ground in this
decomposition of
> the word "transparent" that we can move on?
> > 
> > --Andy Zmolek
> >     Technology & Standards Engineer
> >       CTO Standards
> >         Avaya Inc.
> > 
> >             [email-masked]
> >               +1 720 444 4001
> > 
> > -----Original Message-----
> > From: Melinda Shore [mailto:[email-masked]]
> > Sent: Tuesday, June 19, 2001 11:44 AM
> > To: Pyda Srisuresh; Fleischman, Eric W; 'Andrew Molitor';
> > [email-masked]
> > Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02
> > 
> > > OOP agent are not visible to end-hosts. So, an OOP agent is
transparent.
> > 
> > I wouldn't agree that one follows from the other.
> > If the out-of-path agent effects a change in the behavior
> > of the data/application/what-have-you, it's not transparent.
> > 
> > Melinda
> > 
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/midcom
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 20 Jun 2001 10:32:41 -0400

> middleboxes are doing, how about:

:-)

"Interception" has far fewer connotations.

> not always occur at a NAT device.

Right.  People aren't distinguishing routing from forwarding (we may
never be able to get them to do it again).

> at the application protocol level. 

Transparency is a layer-specific issue.  Application-level gateways can
be "transparent" -- in the strict sense -- to the application if the
payload is delivered faithfully, but they certainly aren't transparent
at the network layer.

I like Randy's strict meaning of transparency as long as the test is
targeted at a specific layer.  We have to have strictness in our use of
terms or we'll have to find new ones in a year.  The term "transparent
routing" thus would mean that "routing" (really forwarding), an IP layer
function, is done without modification to the PDUs of that layer,
i.e. packets.

...Scott

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Jun 2001 11:59:24 -0400

> And the idea of "end-to-end transparency" is debatable. If anything, ALG+NAT
> provides a degree of transparency and typically compatibility across IP
> realms. 

such barefaced lies do not contribute usefully to the discussion.

Keith