Re: Action item from yesterday's meeting

Suresh,

--On 01.12.2004 5:35 Uhr -0800 Pyda Srisuresh wrote:

> Juergen,
>
> I illustrated two applications (FTP & SIMPLE) that exhibit the same problem in
> the midcom MIB, when used in conjunction with twice-NAT. First, you claim,
> FTP-ALG example is not relevant for midcom. Then, you claim, SIMPLE example
> shoudl have a proxy. That a problem can be shown without a proxy enroute seems
> immaterial to you. You mandate requirements in the examples. You even say,
> twice-NAT may not be acceptable for telephony applications. I dont see where
> this line of reasoning is going.

You will probably not be surprised to hear that I have a very different view.
But Melinda asked us to stop arguing because we are not really making progress.

> As far as I know, to disprove the working of a theory, all you need is one
> example to prove where the assertion fails. I gave two. Further, I also pointed
> out how the proposed fix would fix both the problems with the current model.
> Lastly, I know of no example where the proposed fix would fail and the current
> model would work. Perhaps, it is time you proved to the WG why the fix should
> not be adapted and what it breaks if any.

Certainly I have scenarios where your approach fails.
[One is a DNS-ALG we are using at our lab for controlling a twice-NAT that
does not have all bindings to be used already established in advance.]
We would have had to discuss them after you had brought up a convincing
scenario for your proposal in order to compare (dis)advantages of both
alternatives.

But this is not the point here.  You proposed a change and so far I have not
seen convincing arguments for the change.

Thanks,

    Juergen

> Specific responses inline below.
>
> regards,
> suresh
>
>
> --- Juergen Quittek <[email protected]> wrote:
>
>>
>>
>> --On 30.11.2004 9:10 Uhr -0800 Pyda Srisuresh wrote:
>>
>> > My comments inline below.
>> >
>> > regards,
>> > suresh
>> >
>> > --- Juergen Quittek <[email protected]> wrote:
>> >
>> >>
>> >>
>> >> --On 30.11.2004 7:34 Uhr -0800 Pyda Srisuresh wrote:
>> >>
>> >> > Cullen,
>> >> >
>> >> > Thanks for suggesting a new application and simplifying the protocol
>> >> sequence
>> >> > for the apllication. This, I believe, is yet another example
>> illustrating
>> >> the
>> >> > problem with the current model as you will see in my comments below. I
>> am
>> >> > making the following assumptions w.r.t. the example. Do let me know if
>> you
>> >> > disagree. Thanks.
>> >> >
>> >> > 1. I have not seen any mention of proxies. If you assume a proxy, we
>> need
>> >> to
>> >> > redraw the picture with proxy in one of the realms. So, I will assume no
>> >> > proxies.
>> >> >
>> >> > 2. The NAT middlebox in use is a twice NAT. I.e., It has address maps to
>> >> > translate source and destination endpoints of a session flow. A0, A1 are
>> IP
>> >> > addresses in private space and are non-overlapping with A2, A3 in the
>> >> external
>> >> > address space. For simplicity, let us assume, the address A1 is
>> statically
>> >> > mapped to A3 for destination endpoint on outbound flows.
>> >>
>> >> This assumption is usually not feasible.  I definitely cannot expect in
>> >> advance that  all external SIP terminals I ever want to call from an
>> internal
>> >> phone are statically mapped by a twice-NAT.  This twice-NAT needs to map
>> the
>> >> entire outside network into the internal one.  Your assumption is OK with
>> >> IPv6 internally and IPv4 externally.  But it fails for every other
>> >> combination
>> >> of IP versions.
>> >>
>> > [suresh] That is how it works in twice-NAT. You use name service to resolve
>> > names into IP addresses.
>>
>> That's how it works?  This is a very limited view.  Why should we exclude
>> dynamic
>> creation of NAT bindings in the twice-NAT case?  If you established all
>> bindings
>> at a twice-NAT in advance, you do not need to control the NAT, you just need
>> a
>> firewall at the NAT to be controlled.  This would make the story much easier.
>>
>> But this is not acceptable for IP telephony and other applications.
>> How would you communicate with a mobile WLAN phone or PC at a hotspot?
>> Do you claim this does not work at all without having the hot spot's
>> address range mapped at the NAT in advance ???
>>
> [suresh] Juergen - You misunderstood what I said. I was saying that your
> statement that static address mapping is usually not feasible and that it
> usually fails in scenarios other than V4/V6 setup is not correct. Static
> address mapping for destination end points in outbound flows is a fairly common
> setup in twice-NAT.  Dynamic mapping for load share purposes is another
> scenario. For the purposes of this discussion, static address mapping is
> appropriate. Note, large blocks of addresses can be statically mapped. It
> doesnt have to be the Internet. Twice-NAT coudl be setup for accessing specific
> well-known resources, not necessarily the mobile Phone/pc users you have in
> mind.
>
>> >> > 3. There is a midcom agent on UA1 that is responsible for interacting
>> with
>> >> NAT
>> >> > and ensuring that the application works between UA1 and UA2. I.e., there
>> is
>> >> no
>> >> > other entitity outside of UA1 that is acting as midcom agent.
>> >> >
>> >> > 3. Name service is external to this application. I.e., nodes learn of IP
>> >> > addresses for a name from an independent name service in their realm.
>> So,
>> >> when
>> >> > a caller UA1 uses its name service to lookup UA2, it resolves to A1.
>> This
>> >> is
>> >> > because, the private address space in the current example includes just
>> A0
>> >> and
>> >> > A1.
>> >> >
>> >> > 4. In the outset, UA1 uses  name service to resolve UA2. Name service
>> >> returns
>> >> > the IP address of UA2 to be A1.
>> >> >
>> >> > Please see my comments below in-line.
>> >> >
>> >> > regards,
>> >> > suresh
>> >> >
>> >> >
>> >> > --- Cullen Jennings <[email protected]> wrote:
>> >> >
>> >> >>
>> >> >> Ok, I think I understand - combining Juergen's and Martin's emails -
>> just
>> >> to
>> >> >> make sure I have this right, in the case with an outbound call (so UA1
>> >> >> called UA2) and UA1 controls NAT.
>> >> >>
>> >> > [suresh] Right. UA1 calls UA2 using the session tuple of (A0/blah0,
>> >> A1/5060).
>> >> > Twice-NAT would translate the session tuple into (A1/blah1, A3/5060).
>> >> >
>> >> >>                                   +-----+
>> >> >>                                   |  M  |
>> >> >>                                   |  I  |
>> >> >>                                   |  I  |
>> >> >>                                   |  D  |
>> >> >>             UA1                   |  L  |                     UA2
>> >> >>         +------+                  |  E  |                  +------+
>> >> >>         | SIP UA+------------------+  B  +------------------+SIP UA|
>> >> >>         | MIDCOM|                  |  O  |                  |  EXT |
>> >> >>         | AGENT +..................+  X  +..................+      |
>> >> >>         +------+                  +-----+                  +------+
>> >> >>          A0                    A1        A2                 A3
>> >> >>
>> >> >>
>> >> >> UA1 contacts NAT with a PER for (A0/port0, */*) direction inbound and
>> the
>> >> >> NAT returns A2/port2.
>> >> >
>> >> > [suresh] The above PER specifies just one endpoint of a session. One
>> >> end-point
>> >> > alone is not adequate to establish a twice-NAT session. One end-point is
>> >> > adequate to send a binding, not a session. Twice-NAT will translate both
>> >> > endpoints of a session. This is where the two models differ.
>> >> >
>> >> > In the current model - UA1 only knows of A0 and A1. The PER in the MIB
>> only
>> >> > allows A0 & A3 as input. So, the midcom agent on UA1 specifies A0 alone
>> as
>> >> > input. The midcom agent does not know A3 to specify as input.
>> >>
>> >> No. You do not know A1 before you request a binding for A0-A2.
>> >> Based on what input would you know about A1?
>> >>
>> > [suresh] Please refer assumption 4. UA1 learns the address of UA2 in the
>> outset
>> > to A1 using name service.
>> >
>> >> Please remember that A3 is determined by SIP routing of your INVITE
>> message.
>> >>
>> >> You cannot make any assumption about A3 before you receive a reply on your
>> >> INVITE message with a SDP payload.  Then you learn about A3 and must
>> ensure
>> >> that the twice NAT will provide you with a binding A1-A3.  This binding
>> >> cannot be established before A3 is known, which is before you received
>> >> a reply on your INVITE message.
>> >>
>> > [suresh] Please refer assumption 1. There are no proxies to route SIP
>> messages.
>> > If a proxy is assumed,  we need to redraw the picture with a proxy and go
>> over
>> > the steps one more time.
>>
>> I'm sorry, I misunderstood assumption 1.
>> In this case I do not just have problems assumption 2, but also with
>> assumption 1.
>
> [suresh] Sounds like, you are mandating requirements. Why do you mandate a
> proxy enroute for the example?
>
>> If I call into the public network I should not assume that my SIP signaling
>> directly reaches the terminal I want to call, even if I get the address from
>> a redirect server.
>>
>
> [suresh] As I said, there are cases where SIMPLE isnt necessarily used for the
> whole Intenret and public network.
>
> regards,
> suresh
>
>> Kind regards,
>>
>>     Juergen
>>
>> >> Kind 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
>> >>
>> > regards,
>> > suresh
>> >
>> >>
>> >>
>> >> > In the new model - UA1 knows of A0 and A1. The PER in the MIB allows A0
>> &
>> >> A1 as
>> >> > input. So, the midcom agent on UA1 sends a PER for (A0/port0, A1/*),
>> >> direction
>> >> > inbound. Twice-NAT would return (A2/Port2, A3/*) and enable a
>> NAT-session
>> >> for
>> >> > the same.
>> >> >
>> >> >>                       UA1 sends A2/port2 in offer SDP.
>> >> > [suresh] Yup.
>> >> >
>> >> >>                                                         UA2 starts
>> sending
>> >> >> early media to A2/port2 this which gets forwarded to A0/port0.
>> >> >
>> >> > [suresh] This would work only if the NAT-session was setup correctly in
>> the
>> >> > first place by the midcom agent on UA1.
>> >> >
>> >> > In the current model - there is no session permitted from A3/* to
>> A2/port2.
>> >> All
>> >> > that existed was a port-Bind to A2/Port2 for use as destination
>> endpoint.
>> >> >
>> >> > In the new model - the twice-NAT would have setup a NAT-session
>> correctly
>> >> for
>> >> > the tuple (A2/Port2, A3/*), direction inbound. So, no problem for
>> twice-NAT
>> >> in
>> >> > allowing the flow (A3/*, A2/port) in external realm and translatng it
>> into
>> >> > (A1/*, A0/port0) in private realm.
>> >> >
>> >> >>                                                                 Then
>> UA2
>> >> >> sends answer with A3/port3 to UA1.
>> >> >
>> >> > [suresh]
>> >> >
>> >> > In the current model - Assuming the twice-NAT had let the session
>> through,
>> >> the
>> >> > midcom agent on UA1 has no knowledge of A3. So, the payload goes as is
>> to
>> >> UA1.
>> >> > UA1 will have a problem when it sees A3, which it does not recognize.
>> UA1
>> >> might
>> >> > just give up.
>> >> >
>> >> > In the new model proposed - The midcom agent on UA1 will translate
>> A3/port3
>> >> in
>> >> > the payload to A1/Port3 prior to sending the payload to UA1.
>> >> >
>> >> >>                                    UA1 tells NAT to create
>> >> >> (A0/port0,A3/port3) outbound and NAT returns A1/port1 then UA1 starts
>> >> >> sending media to A1/port1 and NAT forwards to A3/port3.
>> >> >
>> >> > [suresh]
>> >> >
>> >> > In the current model - UA1 knows only of A0 & A1. UA1 does not know A3.
>> >> Now,
>> >> > the midcom agent does not A3 either.
>> >> >
>> >> > In the new model proposed - UA1 knows only of A0 & A1. The midcom agent
>> on
>> >> UA1
>> >> > contacts NAT with a PER for (A0/port0, A1/Port3) outbound and the NAT
>> >> returns
>> >> > (A1/Por1, A3/port3). Subsequently, when the UA1 initiates a session
>> >> (A0/port0,
>> >> > A1/Port3), the NAT lets it through.
>> >> >
>> >> >>                                                         UA2 answers and
>> >> >> sends 200 which UA1 accepts then UA1 changes the (A0/port0,*/*) inbound
>> >> >> mapping to be a (A0/port0,A3/port3) inbound mapping.
>> >> >>
>> >> > [suresh] As you can see, there are problems with the current model in
>> >> > twice-NAT. The current model allows only one end-point within a realm to
>> be
>> >> > specified as input. The new model fixes this so two endpoints from the
>> same
>> >> > realm can be specified as input. This in turn allows twice-NAT to setup
>> >> > NAT-sessions.
>> >> >
>> >> >
>> >> >> Did I get this right? I think I understand now - thanks for the
>> >> >> clarification.
>> >> >>
>> >> > [suresh] Hope my comments illustrates the problems with the current
>> model
>> >> and
>> >> > the fix from the new model. Well, that is my perspective, anyways.
>> >> >
>> >> > regards,
>> >> > suresh
>> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> On 11/29/04 5:25 AM, "Juergen Quittek" <[email protected]> wrote:
>> >> >>
>> >> >> > Cullen,
>> >> >> >
>> >> >> > --On 27.11.2004 15:12 h -0800 Cullen Jennings wrote:
>> >> >> >
>> >> >> >> I don't think I fully understand the issue yet
>> >> >> >>
>> >> >> >> Let's ignore FTP for a second but consider any protocol that has
>> >> separated
>> >> >> >> control and media channels. For example, if SIP was used to set of a
>> >> MSRP
>> >> >> IM
>> >> >> >> session - it seems like this problem would happen. Am I confused?
>> >> Actually
>> >> >> I
>> >> >> >> can answer that, I am confused, let me restate the questions - Can
>> you
>> >> >> >> straighten me out on how this all works? I am particularly
>> interested
>> >> in
>> >> >> the
>> >> >> >> case of SIP setting up a session of RTP and TCP sessions between
>> >> >> endpoints.
>> >> >> >>
>> >> >> >> For simplicity sake, lets imagine that internal endpoint A0 is also
>> a
>> >> SIP
>> >> >> UA
>> >> >> >> that can control the middle box.
>> >> >> >
>> >> >> > This case, which is one of the core scenarios of the MIDCOM WG.
>> >> >> > It is fully supported by the current semantics as well as by the
>> >> >> > semantics Suresh suggested even in case of a twice-NAT.
>> >> >> >
>> >> >> > Let's assume that the SIP UA operates behind a NAT and that it has
>> >> >> > already established NAT binding and session that allows communication
>> >> >> > with other SIP UAs and servers across the twice NAT using the SIP
>> >> >> > protocol.  Then SIP signaling itself is not the problem.
>> >> >> >
>> >> >> > In case of an INVITE message issues by the local terminal,
>> >> >> > the SIP UA could operate as follows:
>> >> >> >
>> >> >> >    1. scan the SDP payload and extract the local terminal's address
>> >> >> >       parameters A0 (IP address, port number)
>> >> >> >    2. request address translation of these local address parameters
>> >> >> >       at the NAT using the MIDCOM protocol.
>> >> >> >       Here both semantics under discussion are similar.
>> >> >> >       The only input you have is the local terminal address A0.
>> >> >> >       This is sent to the NAT as input parameter
>> >> >> >       The NAT returns the translated external parameters A2.
>> >> >> >       If you want to apply a more tight security policy, you use
>> >> >> >       the Policy Reserve Rule (PRR) transaction  that does not yet
>> >> >> >       enable NAT service for the address and that may block early
>> >> >> >       media. Otherwise you would use the Policy Enable Rule (PER)
>> >> >> >       that immediately enables the NAT service.
>> >> >> >    3. Then the original invite message needs to be patched replacing
>> >> >> >       the original address parameters A0 with the parameters A2
>> returned
>> >> >> >       by the NAT. The patched message if forwarded following SIP
>> routing
>> >> >> >       rules.
>> >> >> >    4. On receipt of an OK message, the UA scans the SDP payload and
>> >> >> >       extracts the other terminal's address parameters A3.
>> >> >> >    5. Now a mapping for the reverse direction need to be established
>> >> >> >       using the MIDCOM protocol again.  According to the current
>> >> >> >       semantics, the SIP UA sends A0 and A3, the terminal's address
>> >> >> >       parameters, with Suresh's semantics it would be A2 and A3.
>> >> >> >
>> >> >> > For the reverse direction (incoming call, the procedure is similar.
>> >> >> >
>> >> >> > This all works for RTP, RTSP, TCP, etc.
>> >> >> >
>> >> >> > Thanks,
>> >> >> >
>> >> >> >     Juergen
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > =====
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > 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