Re: Action item from yesterday's meeting

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
>>
>
>
> =====
>