Re: Action item from yesterday's meeting

Hi Suresh,

--On 12.11.2004 8:00 Uhr -0800 Pyda Srisuresh wrote:

> Folks,
>
> This is the last outstanding item to be closed for the Midcom MIB design team.
> I belive, all other items have a closure, as of now. Below is the problem
> description and a proposed fix. Please review and let us know if you see any
> issues with the proposal. Thanks.
>
> Problem:
> The semantics assigned to internal/external terminology in figure 7 and the
> subsequent use in sections 6.4 through 6.6 assumes traditional NAT and is not
> applicable to other NAT types.
>
> Take the case of twice-NAT, where the address space of the internal/private
> realm is exclusive from the address space of the external realm. Twice-NAT is
> is different from a traditional NAT scenario, in that the private address realm
> for a traditional space is a superset of the external address space. Say, a
> node on the private realm initiates FTP and uses PORT command. Assume, the
> Midcom-client is on the client node itself. In the above twice-NAT scenario,
> the midcom-client knows only the IP addresses in its private address realm and
> hence is able to supply just the endpoints in its realm (A0, A1) to make the
> midcom PER request for setting up the FTP data session. This is different from
> the semantics in fig 7 & sections 6.4 through 6.6 which assume that the input
> parameters are A0 & A3. Hence, the PRR and PER as defined in these sections
> will not be adequate for the above twice-NAT scenario.
>
> I discussed this with Juergen and Martin. Both agreed the current midcom model
> fails in the above scenario. Essentially, the scenario is not specific to FTP,
> but is applicable to all apps that require a Midcom client (i.e., external ALG)
> to patch payloads which contain IP addresses and ports. With a small change to
> the semantics diagram (figure 7) and terminology, the PRR and PER can be made
> to support all NAT flavors. The suggested fix below would work for all types of
> NAT. In a traditional NAT scenario, there is little difference between the two
> approaches.

Certainly we agree that there is a problem with the ftp PORT command across a
twice-NAT.  However, this is not the only situation where ftp PORT fails;
there are many more.  But ftp has a well known workaround for this problem
which is the ftp PASV command.  With PASV, the client receives the server
address (A3) to connect to and then has exactly what is needed A0 (its own
address) and A3 for configuring the NAT.

With this simple and well known workaround, I do not think that the problem
case you describe gives sufficient reason for changing the semantics we already
agreed on.

    Juergen


> Proposed fix:
> The proposal essentialy is based on the notion that a NAT middlebox provides
> session translations from one address realm to another. The change will not
> alter the functioning of Midcom with traditional NAT. It simply extends support
> to twice NAT (incl NAT-PT) and other NAT devices.
>
> Consider the following diagram.
>
>  +----------+                                                +----------+
>  | internal |A0<-->A1         +-----------+          A2<-->A3| external |
>  | endpoint +-----  Internal -+ middlebox +- External -------+ endpoint |
>  | (A0)     |       realm     +-----------+  realm           | (A3)     |
>  +----------+                                                +----------+
>
>      Figure n: End-2-end application Flow traversal through a middlebox
>
> A0: InsideSrcEndPoint  (Addr:Port, <protocol>)
> A1: InsideDestEndPoint (Addr:Port, <Protocol>)
> A2: OutsideSrcEndPoint (Addr:Port, <protocol>)
> A3: OutsideDestEndPoint (Addr:Port, <Protocol>)
>
> Inputs to a middlebox, i.e., PRR and PER shall be one of A0+A1 (or) A2+A3. The
> NAT middlebox provides translation to one or both end-points, depending upon
> the direction of session, the realm in which the session originated & the NAT
> address map applied.

You suggestion is feasible, but the effort would be high.  First we would have
to go back to the semantics specification, change the PRR and PER semantics,
and update the semantics document consistently.  And then of course we have to
modify several section of the MIDCOM MIB I-D.

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


> As an FYI, I believe, the above fix would also address the issue that Bob
> Penfield raised a couple of months ago in an e-mail dated circa 07/28/04.
>
> Thats all for now. Thank you.
>
> regards,
> suresh
>
> --- Melinda Shore <[email protected]> wrote:
>
>> The design team is deadlocked over an issue related to whether
>> inputs should take the form of an end-to-end description of a
>> data flow or a description of the specific resources on the
>> participating middleboxes.  Suresh has promised to post a
>> description of the problem that he sees to the mailing list, and
>> I would like to get this resolved within the next several weeks -
>> by November 26.  Because the difference is over a matter for which
>> there's already wg consensus it requires a compelling technical
>> argument for a change in the description.
>>
>> 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