Re: Action item from yesterday's meeting

Suresh,

--On 29.11.2004 5:16 Uhr -0800 Pyda Srisuresh wrote:

> Juergen,
>
> I cannot go on in this thread so long as you continue to argue that the FTP
> PORT example used to illustrate the problem is not relevant. That is a basic
> problem.

We had this discussion already face-to-face at the last IETF meeting.
Since then I have seen no new argument.  So why should I have changed
my mind.

I do not see the problem as a relevant one, because
  - for ftp PORT there is a simple workaround recommended by RFC 1579
    already 10 years ago.
  - other RFCs (such as RFC 3235 cited by Martin) recommend that new
    protocols should not be designed in a way that they run into the
    same problem as ftp.

Kind 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 26.11.2004 14:42 h -0800 Pyda Srisuresh wrote:
>> >
>> > Contrary to what Juergen & Martin continue to insist, the semantics in the
>> > midcom MIB simply does not support twice-NAT.
>>
>> I know that you know that this is not a correct statement.
>>
>> The current MIDCOM solution explicitly supports twice-NAT.
>> The only concrete case we identified so far for which the current
>> solution has a problem is the ftp PORT command over twice-NAT.
>>
>> Our ongoing discussion is about whether or not this case is
>> sufficiently relevant  for changing the MIDCOM semantics on
>> which we already have WG consensus.  Considering the
>> availablility of the PASV command and considering the
>> recommendation in RFC 1519 that ftp clients should always use
>> PASV instead of PORT, I do not think your case is sufficiently
>> relevant.
>>
>> 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
>>
>>
>> > I tried to explain this in
>> > several e-mails. The reason is fairly simple. The current MIB assumes that
>> the
>> > input to PRR/PER is constitued of an end-point in the private realm and an
>> > end-point in the external realm. This only makes sense in the case of
>> > traditional NAT where the end-point in externasl realm is also an end-point
>> in
>> > private realm. In a traditional NAT, the private address space is fully
>> > inclusive of the external address space. As a general rule, a midcom agent
>> > cannot know session tuples such that one end-point(<address>:<port>) is in
>> > private realm and the other end-point(<address>:<port>) is in external
>> realm.
>> >
>> > I presented a detailed example of how the above is true with an FTP-ALG
>> while
>> > processing PORT command across a twice-NAT. The problem in no way is
>> limited to
>> > FTP. You pick any application-ALG that knows the tuples of a session it
>> needs
>> > to enable in its realm and use the resulting translation parameters to
>> modify
>> > the payload. You will see the problem loud and clear.
>> >
>> >
>> > regards,
>> > suresh
>> >
>> > --- Juergen Quittek <[email protected]> wrote:
>> >
>> >> Hi Cullen,
>> >>
>> >> --On 24.11.2004 11:23 Uhr +0100 Martin Stiemerling 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.
>> >>
>> >> The only concrete case that Suresh presented is the one of ftp PORT.
>> >>
>> >> RFC 1579 recommended already 10 years ago that the PORT command should
>> >> not be preferred anymore.  Since then, protocol design considered this
>> >> advice and new developed protocols avoid the problem of ftp PORT.
>> >>
>> >> Therefore I agree with Martin that the presented case is not relevant.
>> >> In contrary, it would be a step into the wrong direction adding support
>> >> for unfavorable (and outdated) protocol design.
>> >>
>> >> 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
>> >>
>> >>
>> >> >   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
>>
>
>
> =====
>