Subject: Re: [midcom] Reminder: wg last call

From: Martin Stiemerling <[email-masked]>
Date: Thu, 02 Oct 2003 16:37:44 +0200

Hello,

--On Sunday, September 21, 2003 09:33:03 -0400 Tom Taylor 
<[email-masked]> wrote:

[...]
|>
|> Even if the agent was using an address in the range of 10.1.0.0/16 - say,
|> 10.1.0.1,  and the agent obtains an address, say X1.1, the middlebox has
|> no way to know that all sessions from 10.1.0.1 have to be bound to X1.1.
|> The agent might create a BIND (using PER) at a later time. But, prior to
|> this, if NAT sees any session originating from 10.1.0.1, it would bind
|> the address to one of the available addresses within X1/8 (different
|> from X1.1, as X1.1 is reseved by an agent). Now, lots of chaos ensues
|> because, the PER from the agent would fail.
|>
|
| [PTT] This one is definitely a concern.  It seems to me we have to
| specify in the semantics of PRR that if a reservation is made, it must be
| honoured in subsequent sessions set up automatically by the middlebox
| (need better words).  In the context of your particular example, if the
| middlebox assigns address X1.1 (as address A2) to 10.1.0.1 (address A0)
| as a result of PRR, then while the reservation holds, any subsequent
| BINDs for sessions from 10.1.0.1 must use address X1.1.

We have added this text to the PRR section:
"Once a PRR transaction has reserved an outside address (A2) for an 
internal end point (A0) at the middlebox, the middlebox must ensure that 
this reserved A2 is available in any subsequent PER and PRR transaction."

Martin

|
| [PTT - implementation details snipped]
|>
|> Now, let us consider the case of PER transaction(section 2.3.8). PER in
|> the context of a NAT refers to the agent creating a NAT binding with
|> specific parameters. This will fail if the prameters specified in the
|> bind-create request donot correspond to one or more (in the case of
|> twice-NAT) address map entries. Without reference of an address map
|> entry, the agent has no knowledge of whether to request for an address
|> bind or a port bind. Further, the binding is meaningless without the
|> exact session description to a symmetric NAPT. This is because symmetric
|> NAPT uses different port bindings for the same (private IP address,
|> port) tuple used in different sessions. The port bind may work only for
|> the first session that originates from (provate IP address, port). There
|> are other caveats. Without a PRR preceding the PER, how is the PER to
|> know what external address to bound to? Why not let the middlebox select
|> the external address to bound to?
|>
|> This is why I suggested the tansactions CreateBind, CreateportBind,
|> RequestCreateBind, and RequestCreatePortBind to create binds
|> unequivocally. These transactions use address map as an argument. Either
|> the agent or the middlebox can create a bind.
|
| [PTT] You are arguing that if the agent knows the map entries, it can
| request the specific binding that it needs.  I'll put it the other way:
| the current PER parameters include the internal endpoint address A0, the
| external endpoint address A3, and, if a PRR was performed previously, a
| reference to the A1 and A2 assignments that resulted from that PRR.  What
| other information does the middlebox need to complete the bind?
|
|>
|> Creating binds is not adequate. The agent needs to be able to specify the
|> permitted sessions as well. Without going into the details, i will simply
|> suggest FTP(TCP based) and TFTP(UDP based) are examples of this.
|>
| [PTT] I want to carry on further discussion of this point with a clear
| understanding of your terminology.  Please indicate what additional
| parameters distinguish a session from a bind.
|
| [PTT - remainder snipped]
|

Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
PGP Key at:        http://www.stiemerling.org/stiemerling_nec.gpg
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom