Subject: (NAT) Routing protocol complications

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Mar 1999 15:27:44 +0000

draft-ietf-nat-protocol-complications-00.txt has a short
note on routing updates. However I think it also needs a section
on what would happen if a NAT is positioned between two ISPs
(not something I'd want to encourage, but the idea is to cover all
cases). If you imagine installing a NAT at a boundary across
which BGP4 is in use, what is the impact on BGP4?

  Brian

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Yakov Rekhter <[email-masked]>
Date: Sat, 20 Mar 1999 19:11:52 -0800

Brian,

> which BGP4 is in use, what is the impact on BGP4?

What problem are you trying to solve by using BGP4 at that boundary ?

Yakov.
-

---

From: Matt Holdrege <[email-masked]>
Date: Sat, 20 Mar 1999 21:07:34 -0800

>What problem are you trying to solve by using BGP4 at that boundary ?

I think that Brian wants us to document what might go wrong if two ISP's
tried to exchange routes with BGP-4 through a NAT function. I hope every
agrees this is as silly as cross-breeding a chihuahua with a mastif. But it
doesn't hurt to document all potential forms of complications that NAT can
bring.

However, there could be a good many different implications depending on the
routing architecture on both sides. I don't think I could possibly guess
them all. If anyone is willing to contribute some text to this exercise,
I'd appreciate it.

-

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Mar 1999 15:46:20 +0000

Agreed. I'm not suggesting it's a good thing to do; I'm suggesting
we should document the complications of attempting to do it.
I'm afraid I'm not competent to do so myself.

   Brian

-

---

From: Thomas Narten <[email-masked]>
Date: Mon, 22 Mar 1999 11:47:30 -0500

> doesn't hurt to document all potential forms of complications that NAT can

The TCP MD5 signature option (RFC 2385), designed specifically to
address real threats to BGP, won't work.

This is a specific example where application layer security (which can
be made to work through NAT) may not be sufficient to protect the
application at hand.

Thomas
-

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 22 Mar 1999 17:39:57 +0000 (GMT)

> 'unsubscribe nat' in the body of the message.

Another class of protocols that will break with NAT on ISP (or other)
network boundaries are all(?) the protocols that do PROXY.  In the NAT
meeting we found out that SNMP will not work over NAT, unless if there is
a proxy agent on the NAT itself. I think the same goes for all "proxy
applications. For example RADIUS proxy also fails over NAT (I have tried
it!) unless you place a RADIUS proxy on the NAT itself, in which case it
works (I have also tried that).

Proxies fail because, as far as I know and other may correct me, after
a session initiation from the proxy server, the parent server has to
create a new 'session' of some kind back to the proxy. This is the part
that usualy break. One to one mappings, bidirectional NAT, appropriate
ALGs or proxy implementation on the NAT itself are the usual remedies. The
added problem of proxy services is that usually you have some kind of
security requirements, e.g.: RADIUS may be critical service in a number of
cases.

Also note that proxy applications often run inside a single ISP or
orginisation and thus may be more subjectable to problems with NAT...

Regards
George
-----------------------------
Internet Transport Research |
BTLABS                      |
--------------------------------------------------------------------------
Notice: This contribution is the personal view of the author and does not
necessarily reflect the technical nor commercial direction of British
Telecommunications plc.
--------------------------------------------------------------------------

-

---

From: [email-masked] (Pyda Srisuresh)
Date: Sun, 28 Mar 1999 09:55:59 -0800 (PST)

<... snip>
> network boundaries are all(?) the protocols that do PROXY. 

I dont see the relation. 

>                                                             In the NAT
> a proxy agent on the NAT itself. 

I dont believe, there was any such conclusion.

>                                  I think the same goes for all "proxy

This is way too much generalization.  I dont understand your reference to 
NAT and RADIUS-proxy at all. 

> orginisation and thus may be more subjectable to problems with NAT...

I see proxies and NATs as two orthogonal approaches. I have no idea
what you are talking about.

> George

cheers,
suresh
-

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Mar 1999 10:59:52 +0100

> > network boundaries are all(?) the protocols that do PROXY.

"All" is clearly too general. Any proxy mechanism that transports
IP addresses in the application layer may have a problem,
but I think we have to be specific in each case.
> I dont believe, there was any such conclusion.

The conclusion was, I think, that any MIB variable that contains an
IP address is a potential problem, especially if it is in a
proprietary MIB, in which case it's unlikely that a generic
SNMP ALG can identify it.

> what you are talking about.

Proxies are a particular type of ALG. If they are co-located with
a NAT, and are coded to do so, they can have knowledge of the NAT 
state and perform the appropriate translations. If they are *not*
co-located with the NAT, they have the standard complications
of their respective applications protocols.

    Brian

-

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 29 Mar 1999 10:53:20 +0000 (GMT)

> but I think we have to be specific in each case.

That is why I had a questionmark next to the word all! the problem is not
only the IP addresses in the apps layer but also the fact that some proxy
protocols require both sides to initiate connections from either side.

> SNMP ALG can identify it.

Yes.
> > NAT and RADIUS-proxy at all.

OK here is the test that I tried:

NAS-----Radius Proxy-----NAT----Radius Server

When the NAS requests something from the Radius Proxy the proxy has to
communicate with the Server over NAT. what I am saying is that this did
not work. Do you see the problem now?

George

-

---

From: [email-masked] (Pyda Srisuresh)
Date: Mon, 29 Mar 1999 14:19:22 -0800 (PST)

> but I think we have to be specific in each case.

Sure, looking at specific cases sounds reasonable to me.

> SNMP ALG can identify it.

Sure, I can go with that.

> of their respective applications protocols.

We may be saying the same thing. Anyways, here is what I believe to be the
difference between a Proxy and an ALG.

In a client-server communication, A Proxy enroute has a session with 
the client and a session with the server. An ALG, on the other hand, is
transparent to both client and server. The session is end-to-end between 
client and server. The ALG enroute would use the knowledge of state 
information with NAT to accomplish this.

cheers,
suresh
-

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Mar 1999 10:36:16 +0100

Suresh, we are basically in agreement here. I tend to use the
term ALG to cover both transparent and non-transparent functions,
with proxy as a subset (and remember that some people purport
to sell transparent web proxies, which are ugly beasts). Maybe it
would be better to use the phrase "transparent ALG" anywhere that
it might be ambiguous.

   Brian

-

---

From: Steve Deering <[email-masked]>
Date: Tue, 30 Mar 1999 08:11:47 -0800

> would be better to use the phrase "transparent ALG" anywhere that

Since "transparent" proxies/ALGs usually fail to be completely transparent,
I suggest that the phrase "involuntary ALG" or "involuntary proxy" would
be more accurate.  Or at least require that the word "transparent" always
be enclosed in quotation marks.

Steve
-

---

From: [email-masked] (Pyda Srisuresh)
Date: Tue, 30 Mar 1999 10:37:42 -0800 (PST)

OK. That sounds good.

-

---

From: [email-masked] (Pyda Srisuresh)
Date: Tue, 30 Mar 1999 10:39:53 -0800 (PST)

> be enclosed in quotation marks.

Transparency is the requirement for ALGs. If that is not the case for a 
specific ALG, that applicability of the ALG should be made clear.

cheers,
suresh
-

---

From: John Bartas <[email-masked]>
Date: Tue, 30 Mar 1999 11:54:04 -0800

Hi all,

>would be better to use the phrase "transparent ALG" anywhere that

	I'm concerned about the phase "use the term ALG to cover both transparent
and non-transparent functions". Does this mean you'd refer to a NAT box
which handles basic telnet (which I think is all of them) as having a
"telnet ALG"?

	I would think not, but I want make sure. We have a competitor that seems
to be telling people they have all sort of ALGs for protocols like this
(telnet, http) that In my experience just work over NAT without any special
code, and thus according to my understanding (based on sec 2.4 of Suresh's
new NAT draft) don't require an ALG.

	In fact, I could certainly benfit from a list of protocols which are
non-ALG (telnet), transparent ALG, or non-transparent ALG. Anyone have a
start on such a list? If not, I'd willing to start one an post it for comment.

-JB-

-JB-

#############################################################
          H
(==)o(==) H John Bartas - Main Propeller head
   _I_    H InterNiche Technologies Inc. (408) 257-8014
  /   \   H 21801 Stevens Creek Blvd. Suite 5
  -----   H Cupertino, Ca. 95014
   O O    H [email-masked] (remove foo)
    "     H <http://www.iniche.com/>www.iniche.com
  \___/   H 

-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Mar 1999 14:15:27 +0100

John,

All I can do is quote RFC 2101 at you, which I think was the
first RFC to discuss ALGs. At this point in time I can't
remember which author wrote the following, but it explicitly
is not restricted to transparent ALGs. I stick to my view that
if you want a text to be clear, you need to insert the word
"transparent".

                                ...At the boundary between two (or
      more) routing realms, we may find a spectrum of devices that
      enables communication between the realms.
     
      At one end of the spectrum is a pure Application Layer Gateway
      (ALG). Such a device acts as a termination point for the
      application layer data stream, and is visible to an end-user.  For
      example, when an end-user Ua in routing realm A wants to
      communicate with an end-user Ub in routing realm B, Ua has first
      to explicitly establish communication with the ALG that
      interconnects A and B, and only via that can Ua establish
      communication with Ub. We term such a gateway a "non-transparent"
      ALG.                                     

      Another form of ALG makes communication through the ALG
      transparent to an end user. Using the previous example, with a
      "transparent" ALG, Ua would not be required to establish explicit
      connectivity to the ALG first, before starting to communicate with
      Ub. Such connectivity will be established transparently to Ua, so
      For completeness, note that it is not necessarily the case that
      communicating via an ALG involves changes to the network header.
      An ALG could be used only at the beginning of a session for the
      purpose of authentication, after which the ALG goes away and
      communication continues natively. 

  Brian

-