Re: Action item from yesterday's meeting

--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 ???

>> > 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.
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.

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