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

[<juha.wiljakka@nokia.com>]

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