Re: Action item from yesterday's meeting

Contrary to what Juergen & Martin continue to insist, the semantics in the
midcom MIB simply does not support twice-NAT. 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
> 


=====