ETSI TR 185 012 V3.1.1 (2010-07)

Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Feasibility study of security mechanisms for customer premises networks connected to TISPAN NGN

DTR/TISPAN-05021-NGN-R3

General Information

• Status: Published
• Publication Date: 28-Jul-2010
• Technical Committee: TISPAN 5 - TISPAN NGN Home Networking
• Current Stage: 12 - Completion
• Due Date: 30-May-2010
• Completion Date: 29-Jul-2010

Standards Content (Sample)

Technical Report
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Feasibility study of security mechanisms for customer
premises networks connected to TISPAN NGN

2 ETSI TR 185 012 V3.1.1 (2010-07)

Reference
DTR/TISPAN-05021-NGN-R3
Keywords
gateway, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2010.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TR 185 012 V3.1.1 (2010-07)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 General overview . 9
5 Authentication and authorization mechanisms . 10
5.1 Authentication issues in the Gm' . 10
5.1.1 Applicability and limitations. 11
5.1.2 Implementation details . 11
6 Security Management functionality . 12
7 Firewall. 12
7.1 Basic description . 13
7.2 Applicability and limitations . 13
7.3 Implementation details . 13
7.3.1 Stateful Inspection . 13
7.3.2 Communication technologies. 14
7.3.3 Security Policy . 14
7.3.4 ALG for standard protocols support . 15
7.3.5 Firewall management . 15
7.3.6 Logging . 15
8 Network Access Control (NAC) . 15
8.1 Basic description . 16
8.2 Applicability and limitations . 17
8.3 Implementation details . 17
9 Antispoofing . 18
10 VPN capabilities . 19
10.1 VPN Capability Based on IPsec . 19
10.1.1 Remote access case . 19
10.2 Tunnelling using SSL/TLS . 19
10.3 OpenVPN . 20
10.4 VPN Quarantine . 20
11 Anti-Virus . 20
12 URL/URI filtering and prime user control . 20
13 Unsolicited communication prevention . 20
13.1 Basic description . 21
13.2 Applicability and limitations . 21
13.3 Implementation details . 21
14 Intrusion Detection System . 22
15 Network Address Translation (NAT) . 23
15.1 UPnP IGD V 1.0 . 24
ETSI
4 ETSI TR 185 012 V3.1.1 (2010-07)
15.1.1 Basic description . 24
15.1.2 Applicability and limitations. 25
15.1.3 Implementation details . 25
15.2 Hosted-NAT solution for RTSP based services . 27
15.2.1 Basic description . 27
15.2.2 Applicability and limitations. 27
15.2.3 Implementation details . 28
Annex A: Bibliography . 30
History . 31

ETSI
5 ETSI TR 185 012 V3.1.1 (2010-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
Introduction
The present document explores possible solutions to comply to the security requirements of TS 187 001 [i.1].
ETSI
6 ETSI TR 185 012 V3.1.1 (2010-07)
1 Scope
The present document presents the results of a study into the feasibility of providing security mechanisms to be
implemented in a Customer Premises Network (CPN) that allow the CPN to comply with the security objectives and
requirements of the CPN. The present document identifies the placement of measures in the Customer Network
Gateway (CNG) and in the Customer Network Devices (CNDs) that support the end-to-end security architecture of
NGN release 3 as defined in TR 180 001 [i.20] (NGN-R3 release definition) and TS 187 003 [i.18] (security
architecture).
The present document completes task 7 of the TVRA method defined in TS 102 165-1 [i.21] with due account of the
remainder of the TVRA for CPNs presented in TR 185 008 [i.13] and TR 187 002 [i.17].
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 187 001: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN SECurity (SEC); Requirements".
[i.2] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Vocabulary for 3GPP Specifications (Release 7)
(3GPP TR 21.905)".
[i.3] ISO/IEC 7498-2: "Information Processing Systems - Interconnection Reference Model - Part 2:
Security Architecture".
[i.4] IETF RFC 5209 (June 2008): "Network Endpoint Assessment (NEA): Overview and
Requirements".
[i.5] ETSI TS 133 234: "Universal Mobile Telecommunications System (UMTS); LTE; 3G security;
Wireless Local Area Network (WLAN) interworking security (3GPP TS 33.234 version 9.1.0
Release 9)".
[i.6] ETSI TS 133 203: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; 3G security; Access security for IP-based services
(3GPP TS 33.203 version 9.3.0 Release 9)".
[i.7] ETSI TS 133 110: "Universal Mobile Telecommunications System (UMTS); LTE; Key
establishment between a UICC and a terminal (3GPP TS 33.110 version 9.0.0 Release 9)".
ETSI
7 ETSI TR 185 012 V3.1.1 (2010-07)
[i.8] ETSI TS 185 005: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Services requirements and capabilities for customer networks
connected to TISPAN NGN".
[i.9] ETSI TS 185 006: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Customer Devices architecture and Reference Points".
[i.10] IETF RFC 1827: "IP Encapsulating Security Payload (ESP)".
[i.11] ETSI TR 187 009: "Telecommunications and Internet Converged Services and Protocols for
Advanced Networking (TISPAN); Feasibility study of prevention of unsolicited communication in
the NGN".
[i.12] ETSI TS 185 003: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Customer Network Gateway (CNG) Architecture and
Reference Points".
[i.13] ETSI TR 185 008: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Analysis of security mechanisms for customer networks
connected to TISPAN NGN R2".
[i.14] UPnP Forum: "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0".
NOTE: Available at http://www.upnp.org/standardizeddcps/igd.asp.
[i.15] IETF RFC 2663 (1999): "IP Network Address Translator (NAT) Terminology and
Considerations".
[i.16] Home Gateway Initiative: "Home Gateway Technical Requirements V 1.0".
[i.17] ETSI TR 187 002: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); TISPAN NGN Security (NGN-SEC); Threat, Vulnerability and
Risk Analysis".
[i.18] ETSI TS 187 003: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Security; Security Architecture".
[i.19] ISO/IEC 15408-2: "Information technology - Security techniques - Evaluation criteria for IT
security - Part 2: Security functional requirements".
[i.20] ETSI TR 180 001: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Release 1; Release definition".
[i.21] ETSI TS 102 165-1: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Methods and protocols; Part 1: Method and proforma for
Threat, Risk, Vulnerability Analysis".
[i.22] IETF RFC 3261: "SIP: Session Initiation Protocol".
[i.23] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access Authentication".
[i.24] IEEE 802.16-2009: "IEEE Standard for Local and metropolitan area networks Part 16: Air
Interface for Broadband Wireless Access Systems".
[i.25] Broadband Forum Technical Report TR-069: "CPE WAN Management Protocol v1.1".
[i.26] IEEE 802.1x-2010: "IEEE Standard for Local and metropolitan area networks--Port-Based
Network Access Control".
[i.27] IEEE 802.1B-1992: "Local and Metropolitan Area Network: LAN/MAN Management".
ETSI
8 ETSI TR 185 012 V3.1.1 (2010-07)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
authentication: property by which the correct identity of an entity or party is established with a required assurance
NOTE: The party being authenticated could be a user, subscriber, home environment or serving network
(see TR 121 905 [i.2]).
authorization: granting of permission based on authenticated identification (see ISO/IEC 7498-2 [i.3])
NOTE: In some contexts, authorization may be granted without requiring authentication or identification
e.g. emergency call services.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AKA Authentication and Key Agreement
AV Anti-Virus
B2BUA Back to Back User Agent
C-BGF Core-Border Gateway Function
CND Customer Network Device
CNG Customer Network Gateway
CPN Customer Premises Network
DOS Denial of Services
FTTx Fiber To The x
HGI HoMe Gateway Initiative
HTTP HyperText Transfer Protocol
ICMP Internet Control Message Protocol
IDS Intrusion Detection System
IGD Internet Gateway Device
IGD Internet Gateway Device
IMS IP Multimedia Subsystem
IPSEC Internet Protocol SECurity
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
MCF Media Control Function
MDF Media Delivery Function
MF Media Function
MPLS Multiple Protocol Label Switching
NAC Network Access Control
NAPT Network Address and Port Translator
NAT Network Address Translation
NBA NASS Bundled Authentication
NEA Network Endpoint Assessment
NGN Next Generation Network
NTP Network Time Protocol
P-CSCF Proxy-Call Session Control Function
PDA Personal Digital Assistant
POP3 Post Office Protocol version 3
PUC Prevention of Unsolicited Communication
RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol
SIP Session Initiation Protocol
SMTP Simple Mail Transport Protocol
SOAP Simple Object Access Protocol
SSL Secure Socket Layer
ETSI
9 ETSI TR 185 012 V3.1.1 (2010-07)
TCP Transmission Control Protocol
TLS Transport Layer Security
TVRA Threat Vulnerability and Risk Analysis
UC Unsolicited Communication
UDP User Datagram Protocol
UE User Equipment
UICC Universal Integrated Circuit Card
UPnP Universal Plug and Play
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTM Unified Threat Management
VCR Video Cassette Recording
VPN Virtual Private Network
WAN Wide Area Network
Wi-Fi Wireless Fidelity
xDSL x Digital Subscriber Line
4 General overview
As noted in TR 185 008 [i.13] security problems in the CPN may have two origins:
• internally to the CPN; or
• externally to the CPN.
The CPN, consisting of a CNG and a number of CNDs, is connected to the NGN as if it were a single NGN terminal
connected for signalling purposes through the Gm reference point. Protection of the NGN interconnection and thus
protection of the CPN from NGN attacks is out of scope of the present document but is covered by the following
documents TS 187 001 [i.1], TR 187 002 [i.17] and TS 187 003 [i.18].
The CNG offers services to the CNDs within the CPN and the protection of the CNG and its connected CNDs is
considered in the present document. However the boundary of the CPN may be compromised by the technologies
offered by the CNG and by the CNDs themselves, e.g. a wireless connection between CND and CNG as a broadcast.
The security objectives to be met by the CPN are as follows:
• Confidentiality
1. Information sent to or from a registered user of a CPN should not be revealed to any unauthorized party.
2. Information held within the CNG should be protected from unauthorized access.
3. Details relating to the identity and service capabilities of a CPN user should not be revealed to any
rd
unauthorized 3 party within the CPN or in the wider NGN.
4. Management Information sent to or from a CPN should not be revealed to any unauthorized party.
5. Management Information held within a CPN should be protected from unauthorized access.
• Integrity
1. Information held within the CNG should be protected from unauthorized modification and destruction.
2. Information sent to or from a registered user of a CPN should be protected against unauthorized or
malicious modification or manipulation during transmission.
3. Management Information held within a CNG should be protected from unauthorized modification and
destruction.
4. Management Information sent to or from a CPN should be protected against unauthorized or malicious
modification or manipulation during transmission.
ETSI
10 ETSI TR 185 012 V3.1.1 (2010-07)
• Availability
1. Services provided within a CPN should be available only to authorized users of the CPN upon request
whether they are attached to an access point within the CPN or to an access point within the wider NGN.
2. Services provided within a CPN should be accessible and usable on demand only to authorized users of
the CPN.
• Accountability
1. The use of the CPN services should be recorded such that the owner of a CPN should only be billed for
legitimate use of chargeable CPN and NGN services.
• Authenticity
1. It should not be possible for an unauthorized user to pose as an authorized user when communicating
with an application or other user of a CPN.
2. It should not be possible for a CPN to receive and process management and configuration information
from an unauthorized user.
3. Access to and the operation of services by authorized CPN users should not be prevented by malicious
activity either in the CPN or in the wider NGN.
• Non-Repudiation
1. None.
• Reliability
1. None.
The security functional capabilities for CPN are modelled on the classes of ISO/IEC 15408-2 [i.19] and described in
TS 187 003 [i.18]. The security requirements to the CPN are documented in clause 4.19 of TS 187 001 [i.1].
5 Authentication and authorization mechanisms
The basis of identification may be one or more of the following:
• Something the entity knows such as passwords or keys.
• Something the entity possesses such as UICC or hardware token improving the security of authentication
mechanisms.
• Something inherent to the entity such as fingerprints or retinal characteristics.
The preferred method for user and service authentication is IMS-AKA. To fully implement the IMS-AKA framework, a
UICC is needed into the CPN device which is terminating the IMS security association.
To be compliant with TS 187 001 [i.1], there are other two methods to be considered: Http Digest and NBA.
The mechanisms for the user's authentication in the TISPAN context are enablers for legacy terminals to access the IMS
services. In that sense, IMS-AKA and HTTP Digest should be supported by the CNG and may be supported by CNDs.
If not supported by CNDs, the CNG can play an active role in completing the procedure, as also described in
TS 185 006 [i.9].
5.1 Authentication issues in the Gm'
The Gm' reference point supports the communication between one SIP non-IMS CND (e.g. IETF SIP) and the CNG,
e.g. related to registration and session control. The difference between Gm and Gm' is related to the conformance to the
IMS and to the need to go through the B2BUA to support local services. Further details about Gm' can be found in the
TS 185 003 [i.12] and TS 185 006 [i.9].
ETSI
11 ETSI TR 185 012 V3.1.1 (2010-07)
In order to strength the security within the CPN, it is necessary to define specific authentication mechanism to be
enforced between the CND and the CNG (i.e. Gm'). Threat scenario foresees rogue CND that, violating the local
security of the CPN, reaches the IMS through the CNG and could cause security violations such as theft of services,
Denial of Services, privacy violations and so on.
5.1.1 Applicability and limitations
Given that IETF SIP protocol mandates the support of Digest authentication (RFC 3261 [i.22]), the main security
mechanism to be implemented in the Gm' is the Digest Authentication as described in the RFC 2617 [i.23].
RFC 2617 [i.23] (and its application to the SIP protocol described in the RFC 3261 [i.22]) describes an open framework
with different options to be implemented
(e.g. single-way vs. mutual authentication, integrity protection, and others).
The main issue with SIP Digest is the key management, because subscriber-specific information (e.g. SIP key) needs to
be installed on the CNDs.
This clause does not contain a complete analysis.
5.1.2 Implementation details
Two main use cases are possible for the CNG in the Gm':
1) The SIP B2BUA is collocated in the CNG; or
2) The CNG has not a SIP B2BUA but it is a SIP proxy from the CND point of view.
The local authentication (between the CND and the CNG) on Gm' could be based at least on the following mechanisms:
• SIP Digest authentication as defined in the RFC 2617 [i.23] (and also in the RFC 3261 [i.22]).
• By extending to the service layer the successful identification/authentication performed at the network (or
below) layer, such as IEEE 802.1x [i], MAC address access list or similar layer 2 or 3 mechanisms.
When the SIP B2BUA is available in the CPN (see figure 1), the CNG can perform the IMS authentication on behalf of
the CNDs by using its own IMS (UICC or Digest key) credential.
On the Gm the full IMS-AKA is supported (UICC, AKA and IPSEC).

Figure 1: Gm' with a B2BUA in the CNG
When the CNG acts as a SIP Proxy (figure 2) the CNG cannot perform the authentication on behalf of the local CND
(because a SIP UA is not available in the CNG) and every CND has to be authenticated directly to the IMS. In such a
scenario the SIP non-IMS CND could not authenticate directly to the IMS (e.g. the P-CSCF) by using the TISPAN
Digest authentication mechanism but using the NBA only (note that the Sip Digest defined in the [i.6] is a
customization of the RFC 2617 [i.23]). Anyway the CNG could authenticate the local CND by using several
mechanisms such as Sip Digest (RFC 2617 [i.23]) or access level authentication mechanisms (e.g. MAC address access
list, IEEE 802.1x [i] and so on).
To sum up the CNG with a SIP proxy does not register itself to the IMS, letting the CNDs to register themselves to the
IMS by using their own user credentials. On Gm', the full IMS-AKA is NOT supported (AKA and IPSEC) and possible
restrictions could limit the applicability of TISPAN DIGEST authentication (depending on the SIP Proxy capabilities on
the CNG).
ETSI
12 ETSI TR 185 012 V3.1.1 (2010-07)

Figure 2: Gm' with a SIP Proxy in the CNG
6 Security Management functionality
CNDs Security management functionality addresses both local and remote access security.
For the local security, it will control all the local exchanges between the devices inside the CPN.
Concerning external security, this will cover the cases of remote management, both from the user (e.g. remote activation
of a VCR, remote control of a camera, etc.) or from the network provider (e.g. remote update of the gateway's network
data).
These security tasks may be accomplished with the support of additional features, like the authentication features
embedded in some chipsets (Trusted Platform Module) or UICC inserted in the CNG that may contain credentials,
security algorithms and also other configuration parameters (e.g. some policy rules for the firewall).
7 Firewall
The main mechanism to perform Network Access Control is a firewall, i.e. a system designed to permit, deny or proxy
data traffic to or from the customer's network. A firewall is positioned to control all incoming and outgoing traffic;
hence the CNG is the perfect candidate to perform the firewall functions.
There are several approaches to implements firewall functionalities, such as:
• Packet Filtering: the simplest one inspects each incoming or outgoing IP packet permitting, dropping or
rejecting it on the basis of simple policies (usually defined as access control list) such as the IP address and the
protocol type.
• Stateful Firewall: in addition to a Packet Filter, keeps track on IP packets belonging to the same connection
thereby detecting whether a packet is part of an existing connection or a start of a new connection.
• Application Level Gateway: In addition to a stateful firewall can understand the behaviour of some
applications and can detect e.g. if an illegal protocol is used for a given application or dynamically open ports
for additional sessions belonging to a flow.
Firewalls can divide the network into subnets each one with a different level of security and different security policy as
for example a demilitarized zone.
The firewall could have several configuration alternatives:
• A basic/minimum configuration to ensure a minimum level of security.
• One or several default configurations provided and managed by the operator/service provider through a remote
management system.
• Additional alternative configurations that can depend on the user (e.g. there can be different configurations for
parents and children). These user specific configurations could be managed by the same entity managing the
user identity (e.g. the UICC).
ETSI
13 ETSI TR 185 012 V3.1.1 (2010-07)
7.1 Basic description
In the CPN context, the CNG sits between the NGN and the internal network and this aspect makes the CNG as the
perfect candidate to host the firewall functions. Figure 3 shows a typical scenario where the CNG and the Firewall are
co-located on the same device. The external interface is the one that is connected to the NGN via e.g. xDSL,
IEEE 802.16 [i.24] wireless modem, FTTx, etc., and is often referred to as the unsecure (red) interface. The secure
(black) internal interfaces are connected to the CNDs and can be based on ethernet, IEEE 802.1B [i.] and other wired or
wireless communication technologies.
CPN
CND
CNG
Firewall
CND
Internal External
(secure) (unsecure)
interfaces interface
CND
Outbound traffic Inbound traffic

Figure 3: Firewall in the CPN
The advantages of using a Firewall as shown in the picture (i.e. co-located on the CNG) is that the CNG appears to the
external network (i.e. NGN) as the only point of contact for the CPN, simplifying the protection of the CNDs against
threats that originate on the NGN.
7.2 Applicability and limitations
The Firewall in the CNG should be designed to protect CPN users against threats originating from the external
interface, the NGN. The main goal is to provide a baseline intrusion prevention mechanism protecting against scans for
information and denying all unsolicited inbound traffic in order to stop or limit security attacks originating from the
NGN.
One of the drawbacks related to the Firewalls deployment is that they have typically been difficult to manage and to
configure. This point is particularly important in the CPN context and then the firewall should provide a simple but
effective security experience for example by providing a simple user interface for managing the security policies. A
simple firewall configuration tool should eliminate the configuration problems for end users while still providing
flexibility to customize advanced settings.
This clause does not contain a complete analysis.
7.3 Implementation details
For the protection of the CPN, a firewall should support the some basic features, such as security policy definition and
enforcing, firewall management, logging functions and so on. The following clause describes in details such features.
7.3.1 Stateful Inspection
TS 185 005 [i.8] requires a stateful inspection firewall to secure the CPN: "CPN environment shall be protected with a
stateful firewall function, which may be implemented in the CNG". While a packet filter decides whether or not to drop
a packet based on few information contained in the packet headers (e.g. addressing information), a stateful packet filter
takes its decisions also on the state information that the firewall keeps in memory about all active connections travelling
across it.
ETSI
14 ETSI TR 185 012 V3.1.1 (2010-07)
For connection-oriented protocols, such as TCP, the state of the connection is equivalent to the protocols definition of a
connection (e.g. three-way handshake), whereas for a connection-less protocol, such as UDP, the state of the connection
is the set of packets that are sent between common endpoints (e.g. source IP address/port and destination IP
address/port) without interruption (i.e. the lack of any packets matching that flow for a given period of time e.g. one
minute).
The stateful firewall also performs additional structural checks on network packets. These checks include e.g. quickly
dropping of malformed packet and enforcing the TCP three-way handshake to establish and teardown network
connections.
7.3.2 Communication technologies
The Firewall should be enabled on the local CPN network including all kind of wired and wireless connectivity used on
the CPN, as well as remote access connections such as PPP over Ethernet and Virtual Private Network on the WAN
side of the CNG. Note however that the firewall cannot be enabled when the CNG acts as a network bridge.
IPv6 firewalling is needed in case the CNG supports IPv6 traffic.
7.3.3 Security Policy
The firewall could have several configuration alternatives. In order to simplify the management of the security policy
and still provide a basic level of security to the CPN it is proposed to define one or more security profiles.
As defined by HGI in [i.16] at least the following basic configurations should be supported by the firewall: HIGH
security configuration and LOW security configuration.
The HIGH security configuration foresees the following behaviour:
• For the traffic originated from the NGN toward the CPN (inbound): to refuse connections in TCP, UDP and
ICMP; to authorize already established connections only (and known by the stateful firewall).
Based on the Operator/Service Provider local policy, the firewall could accept incoming connections for
specific services/ports, such as 5060 for SIP (e.g. inbound SIP calls).
• For the traffic originated from the CPN toward the NGN (outbound): to authorize only well known ports, such
as:
- 25 - SMTP
- 80 - HTTP
- 443 - SSL
- 554 - RTSP
- 995 - POP3
- 123 - NTP
- 5060 - SIP
A second alternative basic firewall configuration should be supported by the firewall, the LOW security configuration:
all traffic (inbound and outbound) is authorized by default. Anyway the stateful firewall still performs the security
check on the TCP/UDP active sessions.
Also Internet Control Message Protocol (ICMP) messages should be managed because these messages can be used in
hacking and DOS attacks. The firewall should block or allow specific ICMP options (e.g. Echo Requests, destination
unreachable).
Additional alternative configurations can depend on the user preferences and/or Operator/Service Provider local policy.
ETSI
15 ETSI TR 185 012 V3.1.1 (2010-07)
7.3.4 ALG for standard protocols support
Also a stateful firewall is not effective or could limit specific services with applications that include IP addresses and
TCP/UDP port information in the payload (e.g. FTP, SIP protocols, peer to peer applications). To filter these protocols,
and at the same time permit the access to such services, the firewall has to be augmented by specific Application Level
Gateway.
The firewall should contain support for the NGN standard protocols, such as SIP and RTSP, for the pinholing of the
media ports so that the inbound and outbound traffic could flow through the CNG.
Note that when B2BUA is implemented inside the CNG [i.12], it acts as a SIP ALG; in this case the B2BUA needs to
interact with the firewall.
7.3.5 Firewall management
The firewall should be manageable from the CPN and by the IPS/Operator and it should enable the ISP/Operator also to
upgrade the firewall functionality via download of a new configuration file. To implement this operation, the
management centre downloads to the CNG firewall the configuration file. This file integrates the basic firewall
configuration that includes the HIGH and LOW configurations. As described by HGI in [i.16], DSL Forum
TR-069 [i.25] provides mechanisms for configuration file downloads. However, some additional mechanisms and
specifications could be needed to fully support the CPN security requirements, for example OMA device management
which supports also the security of the management.
The management features should permit the upgrade of the software firewall, the management of the security policy and
the access to the logging information.
7.3.6 Logging
The firewall should have the ability to log network traffic and main security events. Basic logging options should be
supported (by default all logging options should be disabled). The logging function should capture at least the following
events:
• Log of changes to firewall policy.
• Network connection logs, which include dropped and rejected connections (for both inbound and outbound
packets).
• Log of software firewall upgrade events.
The log files should be accessible from the remote management.
NOTE 1: Time synchronization of the device is also important for security reasons (e.g. certification expiration).
NOTE 2: Log storage: It is for further study where to keep/send the log.
8 Network Access Control (NAC)
The Network Access Control (NAC) is a gathering of methods linked to the control of a network's access. In term of
security, these methods aim to control access to a network with policies, including pre-admission endpoint security
policy checks and post-admission controls over where users and devices can go on a network and what they can do. The
combined tools used are usually enforced authentication, security policies for users, management of network resources,
verification tools for security updates, and directory management.
ETSI
16 ETSI TR 185 012 V3.1.1 (2010-07)
8.1 Basic description
The IETF NEA [i.4] architectures have been defined to assess the "posture" of endpoint devices for the purposes of
monitoring compliance to an organization's posture policy and optionally restricting access until the endpoint has been
updated to satisfy the posture requirements. Posture refers to the hardware and software configuration of an endpoint
and may include knowledge that software installed to protect the device (e.g. patches, anti-virus, firewall, host-based
intrusion detection system or any custom software) is enabled and up-to-date.
In the CPN context, the NEA architecture could be used to allow only compliant and trusted Customer Network
Devices (CND), such as PCs, IP-phone, and PDAs, onto the network, restricting or blocking the access (at the network
layer) of noncompliant devices, and thereby limiting the potential damage from security threats and risks. Then NEA
allows operators and service providers to enforce specific security policies on all CND as they enter the customer
premises network, regardless of their access methods, ownership, device types, application configurations, etc.
The general NEA architecture is a client-server architecture, where the server component evaluates the posture of an
endpoint device and provides network authorization decisions. Moreover the NEA server interacts with the NEA client
(i.e. CND) by means of a specific software agent installed on each managed element. Usually such agents have a small
footprint and low impact on the CND activities. In the CPN context, the Customer Network Gateway (CNG) is the
natural candidate to perform the NEA server role.
Figure 4 shows the general NAC architecture for a CPN environment. Depending on the business model and on the
technologies adopted to implement the NAC services, different scenarios are possible. The main points to highlight are
the following:
• CND controlled by means of a specific agent (called NAC client in the figure) able to check the local posture
and enforce the policy locally. The agent could be both, installed permanently on the CND (e.g. at subscription
time, the customer installs the agent on his CNDs such as PC, laptop and so on) or on demand and temporary
installed by means e.g. of Java applet of other mobile code system.
• CND without any agent (permanent or temporary). Usually such devices cannot be managed by an agent
because of their legacy/closed operative system (e.g. printer) or because explicitly required by the business
model of the NAC service. Without an agent, it is necessary to assess the posture of the CND remotely by
checking for vulnerability to attacks from the network. For example the CNG could be equipped with specific
software able to look for open TCP/UDP ports, detect the Operative System type and detect applications
running on a target system (i.e. the CND to be assessed). It is also necessary to define a separate enforcing
point, e.g. on the GNG.
• NAC server implemented within the CPN e.g. in the CNG. In this case the NAC server is responsible for the
security of the local CPN and checks the posture of the local CNDs depending on the policies locally defined
by the customer or centrally defined by the Service Provider/Operator.
• The NAC server can reside inside the Operator's management network (e.g. in the NGN outside the CPN) and
no specific software has to be installed on the CNG.

Figure 4: CPN NAC architecture
ETSI
17 ETSI TR 185 012 V3.1.1 (2010-07)
8.2 Applicability and limitations
NAC (and NEA) frameworks could provide significant benefits to the security of the CPN environments, among them
the following are the most relevant:
• Assessment and identification of non-compli
...