Re: Action item from yesterday's meeting

Suresh,

--On 24.11.2004 17:33 Uhr -0800 Pyda Srisuresh wrote:

> Juergen,
>
> If you are saying that FTP-ALG is not required, that is simply not true.

I was just saying that I do not see a problem with the PORT command
as long as PASV is available.

Here is a quote from RFC 1579 written by Steve Bellovin in 1994:

   "Recommendation

      We recommend that vendors convert their FTP client programs
      (including FTP proxy agents such as Gopher [3] daemons) to use PASV
      instead of PORT.  There is no reason not to use it even for non-
      firewall transfers, and adopting it as standard behavior will make
      the client more useful in a firewall environment."

I do not say that ftp-ALGs are not required at all.
What I say is that enabling the PORT command across a NAT is not a
sufficient reason for installing a ftp-ALG.

This does not exclude that ftp-ALGs may be very useful for solving
other problems.

- One of them is firewall control.  In a highly secured/restricted
  environment even the PASV command might need a ftp-ALG in order
  to work across a firewall.  Actually, Martin and I implemented
  such an ALG two years ago.

- Considering the PASV command as more secure for the client and the
  PORT command as more secure for the server, the ideal ftp-ALG
  coverts a PASV command from the client into a PORT command to the
  server as for example described at
  <http://www.clavister.com/manuals/ver8.4x/manual/ftp_alg.htm>.

- Another reason for an ftp-ALG may be policy control.  The ALG
  could limit ftp access to a given set of servers and/or clients.

- ... and probably there are more good reasons for using ftp-ALGs.

> Users have the option to use PASV command. But, they dont have to. PORT and EPRT
> commands are still supported FTP commands. NAT vendors donot mandate that users
> use PASV command.
>
> PORT command simply illustrates the problem. Demonizing PORT commnd does not
> make the problem non-existant. Have a good weekend.

I did not intend to demonize anything - at least no further than
RFC 1579 did already ;-)

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


> regards,
> suresh
>
> --- Juergen Quittek <[email protected]> wrote:
>
>> Suresh,
>>
>> --On 24.11.2004 8:37 Uhr -0800 Pyda Srisuresh wrote:
>>
>> > Martin,
>> >
>> > Melinda suggested that I come up with an example to illustrate that the
>> current
>> > sematics and MIB is problematic for certain types of NATs. I did this with
>> FTP
>> > and PORT command in twice NAT scenario. You claim the FTP example is not
>> real.
>> > That simply is not true. FTP is a common ALG used with NATs and is very
>> real.
>> > That you dont like the FTP ALG would not make the problem go away. There is
>> a
>> > real problem with the MIB, the way it is. And, there is a simple fix to it.
>> >
>> > Hope you understand. Thanks.
>>
>> I do understand that you solve the problem of ftp using the PORT command.
>> But you are solving a problem, that has been solved already a long time ago.
>> There is the ftp PASV command and every decent ftp client supports (if not
>> prefers) it.  Therefore, I still do not see a reason for changing the
>> semantics.
>>
>> Thanks,
>>
>>     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
>>
>>
>> > regards,
>> > suresh
>> >
>> > --- Martin Stiemerling <[email protected]> wrote:
>> >
>> >> Hi Cullen,
>> >>
>> >> --On Dienstag, 23. November 2004 17:31 Uhr -0800 Cullen Jennings
>> >> <[email protected]> wrote:
>> >>
>> >> |
>> >> | I have not been participating closely I the group so I may have a
>> complete
>> >> | clueless opinion here but ... It seems that people are continuing to
>> >> | deploy things like twice NAT, if we can make the protocol work in these
>> >> | cases without causing major complexity or big issues to the protocol,
>> why
>> >> | wouldn't we? It seemed to me that Srisuresh was proposing that a few
>> >>
>> >> Just to make it clear: The MIDCOM MIB already supports twice-NATs and the
>> >> semantics did so from the beginning.  So in this sense there is anyway no
>> >> change needed.
>> >>
>> >> | simple changes could make the protocol be about the same in the case we
>> >> | currently have plus make it usable for a few more cases.
>> >>
>> >> The case presented do not represent a real case in my opinion.
>> >>
>> >>   Martin
>> >>
>> >> |
>> >> |
>> >> | On 11/16/04 10:19 AM, "Melinda Shore" <[email protected]> wrote:
>> >> |
>> >> |> I'm intending to get this issue closed in the next week (or sooner,
>> >> |> if possible).  Juergen and Suresh have presented their concerns, and
>> >> |> if there are other people who have opinions or questions or even
>> >> |> just want to indicate how they're leaning, that would be a big help.
>> >> |>
>> >> |> 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
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> midcom mailing list
>> >> [email protected]
>> >> https://www1.ietf.org/mailman/listinfo/midcom
>> >>
>> >
>> >
>> > =====
>> >
>> >
>> > _______________________________________________
>> > midcom mailing list
>> > [email protected]
>> > https://www1.ietf.org/mailman/listinfo/midcom
>>
>>
>>
>>
>>
>
>
> =====
>
>
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom