[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: 3gpp-analysis-05 / new comments in the issue tracker



 Hi, Pekka!

Many thanks for your comments (again)! I have now updated issues 11, 9 and 2, and created one new issue (number 12).

Our issue tracker can be found here:
http://danforsberg.info:8080/draft-ietf-v6ops-3gpp-analysis/

(currently, there are 5 open issues)

Next steps: I aim to reply to Pekka's comments / comment suggested text early next week and compose revision -06 during next week (if feasible).

Cheers,
	-Juha W.-

-----Original Message-----
From: ext Pekka Savola [mailto:pekkas@netcore.fi]
Sent: 19 September, 2003 09:13
To: v6ops@ops.ietf.org
Subject: 3gpp-analysis-05: security considerations


Hi,

As has already been raised as an issue, the security considerations 
section seems pretty weak at the moment, to be refined when we have a 
better grasp on which mechanisms and techniques to recommend.

Assuming we'd end up with something like I've proposed in the previous 
messages, I've written a bit of text to replace the current security 
considerations section.

=====
Security Considerations

There are some generic security considerations when moving to dual-stack
IPv4/IPv6 deployment which are not analyzed at length here.  Two examples
of these are ensuring that the access controls and firewalls have similar
(or known) security properties with both IPv4 and IPv6, and that enabling
IPv6 does not jeopardize the access to the IPv4 services (e.g., in the
form of misbehavior towards DNS AAAA record lookups or operationally worse
quality IP transit services).

This memo recommends the use of a relatively small number of techniques,
which all of them have their own security considerations, including:

 - native upstream access or configured tunneling by the 3GPP network 
operator,

 - use of IPv4 and IPv6 routing protocols to ensure redundancy,

 - use of locally-deployed specific-purpose protocol relays and 
application proxies to reach IPv4(-only) nodes from IPv6-only UEs, and

 - a specific, yet-undefined, mechanism for SIP signalling and media 
translation,

These (except for the last one, naturally) have relatively well-known
security considerations, which are also discussed in the specific
documents.  However, in particular one should note that a proper
configuration of locally-deployed relays and proxies is very important, so
that the outsiders will not have access to them, to be used for abuse,
laundering attacks, or circumventing access controls.

In particular, this memo does not recommend any of the following 
techniques which each have a number of security issues, not further 
analyzed here:

 - NAT-PT or any other generic translation mechanism,

 - automatic tunneling mechanisms, or

 - the use of IPv6 transition mechanisms at the UEs.
=====

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings