Re: Action item from yesterday's meeting

Hi Suresh,

--On 16.11.2004 0:14 Uhr -0800 Pyda Srisuresh wrote:

> Juergen,
>
> All flavors of NAT boxes supporting FTP-ALG do support "PORT cmd". I donot know
> what you mean by "there are many situations where ftp PORT fails" in a NAT box.

Did you ever try ftp PORT behind a NAT without ftp-ALG?
Obviously this fails, while usually ftp PASV still works.

> "PASV" command is recommended as a work around in firewalls and traditional NAT
> devices only because that obviates the need for FTP-ALG.

Exactly.  Typically, there is no ftp-ALG - at least this is my experience.
And the reason why there is no ftp-ALG is that you don't need one because you
can use ftp PASV.  There is no good reason to deploy a ftp-ALG at a traditional
NAT.

> Anyways, FTP (with
> "PORT" cmd) is not the only application that fits the description below. There
> are several others. Real-Audio application has the same issue when the client
> operates in UDP mode.

The typical Real-Audio session I am used to uses well known servers that are
resolved by DNS.  Then you either have the server's A3 address or you need
a DNS-ALG that establishes an address translation for the server into your
local realm beforehand.  In both cases there are no problems with the current
semantics.

> Client specifies a port to which the server initiates a
> data connection. Netshow/Windows Media Services/MMS has the same issue. Client
> specifies the IP address and port to which the server initiates a UDP data
> session. And, so on...
>
> As for updating the MIDCOM MIB, I donot see the effort as being high.>

This is not a MIB design discussion.  This is a pure semantics discussion.
Certainly, we could implement the semantics you are discussion in the MIB
with some effort.  But first the WG would have to agree on changing semantics
that were discussed and agreed on about a year ago.

> I
> believe, we can state early on in the draft where it differs from the semantics
> draft.

This implies defining the new semantics of PRR and PER.

Best regards,

    Juergen

> It might be as simple as a paragraph of text below. If there are no
> objecions, I promise to complete all the edits related to this in the MIDCOM
> MIB draft over a weekend.
>
> regards,
> suresh
>
> --- Juergen Quittek <[email protected]> wrote:
>
>> Hi Suresh,
>>
>> --On 12.11.2004 8:00 Uhr -0800 Pyda Srisuresh wrote:
>>
>> > Folks,
>> >
>> > This is the last outstanding item to be closed for the Midcom MIB design
>> team.
>> > I belive, all other items have a closure, as of now. Below is the problem
>> > description and a proposed fix. Please review and let us know if you see
>> any
>> > issues with the proposal. Thanks.
>> >
>> > Problem:
>> > The semantics assigned to internal/external terminology in figure 7 and the
>> > subsequent use in sections 6.4 through 6.6 assumes traditional NAT and is
>> not
>> > applicable to other NAT types.
>> >
>> > Take the case of twice-NAT, where the address space of the internal/private
>> > realm is exclusive from the address space of the external realm. Twice-NAT
>> is
>> > is different from a traditional NAT scenario, in that the private address
>> realm
>> > for a traditional space is a superset of the external address space. Say, a
>> > node on the private realm initiates FTP and uses PORT command. Assume, the
>> > Midcom-client is on the client node itself. In the above twice-NAT
>> scenario,
>> > the midcom-client knows only the IP addresses in its private address realm
>> and
>> > hence is able to supply just the endpoints in its realm (A0, A1) to make
>> the
>> > midcom PER request for setting up the FTP data session. This is different
>> from
>> > the semantics in fig 7 & sections 6.4 through 6.6 which assume that the
>> input
>> > parameters are A0 & A3. Hence, the PRR and PER as defined in these sections
>> > will not be adequate for the above twice-NAT scenario.
>> >
>> > I discussed this with Juergen and Martin. Both agreed the current midcom
>> model
>> > fails in the above scenario. Essentially, the scenario is not specific to
>> FTP,
>> > but is applicable to all apps that require a Midcom client (i.e., external
>> ALG)
>> > to patch payloads which contain IP addresses and ports. With a small change
>> to
>> > the semantics diagram (figure 7) and terminology, the PRR and PER can be
>> made
>> > to support all NAT flavors. The suggested fix below would work for all
>> types of
>> > NAT. In a traditional NAT scenario, there is little difference between the
>> two
>> > approaches.
>>
>> Certainly we agree that there is a problem with the ftp PORT command across a
>> twice-NAT.  However, this is not the only situation where ftp PORT fails;
>> there are many more.  But ftp has a well known workaround for this problem
>> which is the ftp PASV command.  With PASV, the client receives the server
>> address (A3) to connect to and then has exactly what is needed A0 (its own
>> address) and A3 for configuring the NAT.
>>
>> With this simple and well known workaround, I do not think that the problem
>> case you describe gives sufficient reason for changing the semantics we
>> already
>> agreed on.
>>
>>     Juergen
>>
>>
>> > Proposed fix:
>> > The proposal essentialy is based on the notion that a NAT middlebox
>> provides
>> > session translations from one address realm to another. The change will not
>> > alter the functioning of Midcom with traditional NAT. It simply extends
>> support
>> > to twice NAT (incl NAT-PT) and other NAT devices.
>> >
>> > Consider the following diagram.
>> >
>> >  +----------+                                                +----------+
>> >  | internal |A0<-->A1         +-----------+          A2<-->A3| external |
>> >  | endpoint +-----  Internal -+ middlebox +- External -------+ endpoint |
>> >  | (A0)     |       realm     +-----------+  realm           | (A3)     |
>> >  +----------+                                                +----------+
>> >
>> >      Figure n: End-2-end application Flow traversal through a middlebox
>> >
>> > A0: InsideSrcEndPoint  (Addr:Port, <protocol>)
>> > A1: InsideDestEndPoint (Addr:Port, <Protocol>)
>> > A2: OutsideSrcEndPoint (Addr:Port, <protocol>)
>> > A3: OutsideDestEndPoint (Addr:Port, <Protocol>)
>> >
>> > Inputs to a middlebox, i.e., PRR and PER shall be one of A0+A1 (or) A2+A3.
>> The
>> > NAT middlebox provides translation to one or both end-points, depending
>> upon
>> > the direction of session, the realm in which the session originated & the
>> NAT
>> > address map applied.
>>
>> You suggestion is feasible, but the effort would be high.  First we would
>> have
>> to go back to the semantics specification, change the PRR and PER semantics,
>> and update the semantics document consistently.  And then of course we have
>> to
>> modify several section of the MIDCOM MIB I-D.
>>
>> Best regards,
>>
>>     Juergen
>> --
>> Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
>> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
>>
>>
>> > As an FYI, I believe, the above fix would also address the issue that Bob
>> > Penfield raised a couple of months ago in an e-mail dated circa 07/28/04.
>> >
>> > Thats all for now. Thank you.
>> >
>> > regards,
>> > suresh
>> >
>> > --- Melinda Shore <[email protected]> wrote:
>> >
>> >> The design team is deadlocked over an issue related to whether
>> >> inputs should take the form of an end-to-end description of a
>> >> data flow or a description of the specific resources on the
>> >> participating middleboxes.  Suresh has promised to post a
>> >> description of the problem that he sees to the mailing list, and
>> >> I would like to get this resolved within the next several weeks -
>> >> by November 26.  Because the difference is over a matter for which
>> >> there's already wg consensus it requires a compelling technical
>> >> argument for a change in the description.
>> >>
>> >> Thanks,
>> >>
>> >> Melinda
>> >>
>> >>
>> >> _______________________________________________
>> >> midcom mailing list
>> >> [email protected]
>> >> https://www1.ietf.org/mailman/listinfo/midcom
>> >>
>> >
>> >
>> > =====
>> >
>> >
>> > _______________________________________________
>> > midcom mailing list
>> > [email protected]
>> > https://www1.ietf.org/mailman/listinfo/midcom
>>
>>
>>
>>
>>
>
>
> =====
>