Re: Action item from yesterday's meeting

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.

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
> 


=====