Subject: draft-ietf-v6ops-3gpp-analysis-09.txt / IESG comments on IMS Scenario 1

From: <[email-masked]>
Date: Tue, 20 Apr 2004 17:56:41 +0300

Hi!

3GPP Analysis has -09 received some comments from the IESG and I start the mailing list discussion with the comments considering IMS Scenario 1. There are two comments from Allison and Jon:

=====================================
(1)
Commented by:Mankin, Allison  
Comment:My understanding is that this analysis is for 3GPP, rather than reflecting an existing
fully-formed 3GPP analysis, so that we influence what 3GPP thinks.

3GPP desperately needs to grapple with a robust model for IMS systems when
they communication with IPv4 only hosts.  (They also needs a model for those
systems to deal with expressing a preference for IPv6 usage should vendors
provide IPv4 IMS capability). 

The document wisely says that the SIP WG can do a good job of providing this
model, but then unwisely both describes a model and references a more
detailed draft.  Both models are not good cross-area products, since they
design a SIP ALG and a NAT-PT structure for SIP's SDP. 

Since SIP terminates the connection endpoints at proxies, it can change
the Internet protocol at those points, therefore, it would be possible to
provide a reverse NAT for IPv4 addresses and route them to translating
proxies at a boundary point where the IMS system had dual stack
capability (this is just one idea).  The media situation is harder, but
the review of this needs to consider capabilities such as terminating
the media at a mixer and changing the Internet protocol there (SDP
rewriting is not OK), using only DNS names by policy, so both ends
of the media user could use a generic transition mechanism not
specialized into 3GPP.

My recommendation is that this section only contain a strong referral
with a deadline for the SIP/SDP community to do this work, rather
than sketching problematic approaches.
======================================

I fully agree that we need a referral with a deadline for the SIP/SDP community, and we could use stronger wording than we have in -09 (would a good deadline be by the end of this year?). It is clear that we leave the closer details of the solution to be specified by the SIPpish wgs - specifying new mechanisms is out of the scope of this document. The current text says:

   "This section presents higher level details of a solution based on 
    the use of a translator and SIP ALG. [3GPPtr] provides additional 
    information and presents a bit different solution proposal based on 
    SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to 
    solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF 
    SIP wg(s)."

Removal of [3GPPtr] informative reference is needed?

I understand that rewriting SDP is one of your concerns. But would it be acceptable in cases when a solution is needed, and there is no other way around to solve the problem? We could state in the draft that alternative mechanisms will be developed in the future to solve the problem in some other way than rewriting the SDP, and when those mechanisms will be available, SDP rewriting should not be applied any more. And write text on the problems with rewriting SDP.

Anyway, I wouldn't like to remove all details in section 4.1, because that would make our document less useful.

Comments on the mailing list are more than welcome!

======================================
(2)
Commented by:Peterson, Jon  
Comment:The use of SIP ALGs has security implications - namely, it precludes certain security mechanisms (namely S/MIME) described in RFC3261 which might protect the integrity or confidentiality of SDP, or even SIP headers in some instances. While this document does suggest that more work needs to be done in the SIPpish WGs to address the SIP 6-to-4 problem, it describes no other solution than the use of SIP ALGs. Accordingly, a mention of the effects of ALGs on SIP security in the Security Considerations is probably warranted.
======================================

We could mention that the usage of an ALG has known security issues in the Security Considerations section. And in the case the SIP messages are S/MIME protected, then the usage of the SIP-ALG might not be possible. Would that address the concerns?

Best Regards,
	           -Juha W.-

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 Apr 2004 14:19:44 +0300 (EEST)

Feedback is sought from the WG -- see below..

On Tue, 20 Apr 2004 [email-masked] wrote:
[...]
> I fully agree that we need a referral with a deadline for the
> SIP/SDP community, and we could use stronger wording than we have in
> -09 (would a good deadline be by the end of this year?). It is clear
> that we leave the closer details of the solution to be specified by
> the SIPpish wgs - specifying new mechanisms is out of the scope of
> this document. The current text says:
> 
> I understand that rewriting SDP is one of your concerns. But would
> it be acceptable in cases when a solution is needed, and there is no
> other way around to solve the problem? 

Clarification: do you mean, "no other way around to solve the problem 
_at the moment_"?

Note that such interop is not required when you communicate between
3GPP boxes as no translation is needed, just externals -- this might
not be the number one critical problem (not sure), so if we were able 
to find (or even publish) a solution before the year's end (for 
example), it might be good enough.

> We could state in the draft
> that alternative mechanisms will be developed in the future to solve
> the problem in some other way than rewriting the SDP, and when those
> mechanisms will be available, SDP rewriting should not be applied
> any more. And write text on the problems with rewriting SDP.
>
> Anyway, I wouldn't like to remove all details in section 4.1,
> because that would make our document less useful.
>

(co-chair hat on)
 
My understanding of Allison's concern was that the document goes on
too much depth describing a particular solution (or a class of
solutions), while this solution has a number of big problems, and
another approach would be better .. but the details of the approach 
would have to be worked out (in very short order).

So, if we agree with that that view, the options would appear to be 
like:

 1) describe the problems with currently proposed mechanisms, and 
    recommend against using them (if already being used) after a 
    better solution is found.  This has a problem that undeploying 
    stuff is very difficult, and if it's already out there, giving 
    IETF "blessing" to a temporary deployment may not be a good idea.
    (This may not clear Allison's Discuss.)

 2) just describe the problem, and get the balls rolling quickly to 
    find the good solution. The problem with this is that it 
    doesn't give any idea about what kind of solution that would be.
 
    2.a) include the justification why currently proposed mechanisms 
         are not good.

    2.b) omit the discussion.

 3) describe the problem, and try to give very high view details of
    a potential solution (e.g., as Allison already stated), and get 
    the balls rolling quickly to find the solution.  The problem with 
    this is that as the details are not yet clear, it might be 
    inappropriate to just describe a sketch here, as it could change 
    still.

    3.a) include the justification why currently proposed mechanisms
         are not good.
                                                                                                
    3.b) omit the discussion.

 4) delay this document until work has gone further.  That is, there 
    are a number generic suggestions, lacking the specifics.  Maybe 
    this is an indicator that we should try to work out more details 
    of the approaches first, and only publish the document when it has 
    enough details to be (more) useful.  The problem with this is that it
    delays the publication for parts which would already be considered 
    useful.

Is this a reasonably good representation of the possibilities? 

Thoughts on the way forward?  Send them on the list by next Tuesday,
27 April (at the latest).

Thanks!

(co-chair hat off)

(By the way, I wrote "get the ball rolling" -- but I'm REALLY, really 
hoping that the ball would already be going down the slope...)

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Apr 2004 15:20:44 +0300 (EEST)

(co-chair hat on)

There were no replies to this query for preferences how to solve this,
so let's consider the following, slightly modified, text proposed by
Allison.

If you have objections/enhancements to this, please comment on Monday
5th April at the latest so that we could move on with this.  Thanks!

(Based on this proposal, I'm confident that addressing Jon's issues
with SDP editing could be settled easily.)

======
4.1 UE Connecting to a Node in an IPv4 Network through IMS

    This scenario occurs when an IMS UE (IPv6) connects to a node in
    the IPv4 Internet through the IMS, or vice versa. This happens when
    the other node is a part of a different system than 3GPP, e.g. a
    fixed PC, with only IPv4 capabilities.

    The first priority is to upgrade the legacy IPv4 nodes to dual-
    stack, eliminating this particular problem in that specific
    deployment.

    Still, it is difficult to estimate how many non-upgradeable legacy
    IPv4 nodes need to communicate with the IMS UEs. It is assumed that
    the solution described here is used for limited cases, in which
    communications with a small number of legacy IPv4 SIP equipment are
    needed.

[these first three paragraphs were unmodified]

    As the IMS is exclusively IPv6 [3GPP 23.221], for many of the
    applications in the IMS, some kind of translators may need to
    be used in the communication between the IPv6 IMS and the
    legacy IPv4 hosts in cases where these legacy IPv4 hosts cannot
    be upgraded to IPv6.

    This section gives a brief analysis of the IMS interworking
    issues, and presents a high level view of SIP within the IMS.
    The authors recommend that the IETF specify a detailed solution
    of the general SIP/SDP/media IPv4/IPv6 transition problem as
    a task within the SIP WGs as soon as possible.
  
    As control (or signaling) and user (or data) traffic are separated
    in SIP calls, and thus, the IMS, the transition of IMS traffic
    from IPv6 to IPv4 must be handled at two levels:

              1)Session Initiation Protocol (SIP) [RFC3261], and 
                 Session Description Protocol (SDP) [RFC2327] [RFC3266] 
                 (Mm-interface) 
              2)the user data traffic (Mb-interface) 

    SIP carries an SDP body containing the addressing and other 
    parameters for establishing the user data traffic (the media).

    Figure 1 shows a signaling edge for SIP and SDP, a dual stack SIP
    proxy at the border between the 3GPP IPv6-only IMS network and the 
    IPv4 systems.

    In a possible approach to communicating, this edge could contain a SIP
    ALG, which would change the IP addresses transported in the SIP
    messages and the SDP payload of those messages to the appropriate
    version.   This approach would have the drawback (like other SDP
    rewriting solutions) of impacting authentication mechanisms that
    may be needed for other purposes.   Moreover, this approach would
    not take advantage of SIP's ability to use proxy routing, nor of SDP's
    ability to carry multiple alternative addresses.  These intrinsic
    features of SIP and SDP require a more detailed analysis, but they
    would yield benefits.  The SIP ALG approach requires NAT-PT 
    (with the issues described in appendix A), because the IMS-side
    IPv6 addresses must be assigned IPv4 addresses for reachability
    from the legacy IPv4 side shown in Figure 1.  The approach based
    on intrinsic SIP proxy routing would not require assignment of
    temporary IPv4 addresses to the IPv6 IMS endpoints; instead they
    would be reached via an IPv4-side address of a SIP proxy
    acting for them.  This SIP proxy would be doing normal SIP 
    processing; it would be as scalable as any SIP proxy.
    
    On the user data transport level, the analysis raises other issues:
    the IMS data is time-sensitive, so NAT-PT IPv6-IPv4 protocol
    translation (with the scalability concerns raised in Appendix A)
    may look simplest, but needs a skeptical look.  Alternatives 
    include routing to a transcoder, whose task is to terminate an
    IPv6 stream and start an IPv4 stream.  Again, this requires
    a more detailed analysis.

    For each of the protocols, there has to be interoperability
    for DNS queries; see section 2.4 for details.  

          +-------------------------------+ +------------+ 
          |                      +------+ | | +--------+ | 
          |                      |S-CSCF|---| |SIP edge| |\ 
       |  |                      +------+ | | +--------+ | \ -------- 
     +-|+ |                       /       | |     |      |  |        | 
     |  | | +------+        +------+      | |     +      |   -|    |- 
     |  |-|-|P-CSCF|--------|I-CSCF|      | |     |      |    | () | 
     |  |   +------+        +------+      | |+----------+| /  ------ 
     |  |-----------------------------------||[ALG?]    ||/ 
     +--+ |            IPv6               | |+----------+|     IPv4 
      UE  |                               | |Interworking| 
          |  IP Multimedia CN Subsystem   | |Unit        | 
          +-------------------------------+ +------------+ 
     
           Figure 1: UE using IMS to contact a legacy phone 

    Figure 1 shows a generic SIP signaling edge - a ALG-like replacement
    of the IPv6 addresses with IPv4 addresses using limited subsets of
    NAT-PT [RFC2766] is a possible approach, but exploiting SIP's proxy
    routing to allow the dual homed SIP edge to make the address change
    without a translator is a promising alternative without the scaling
    problems of NAT-PT (appendix A).
==============