FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
SIXTH FRAMEWORK PROGRAMME
PRIORITY 2
“Information Society Technologies”
Project acronym: SEINIT
Project full title: Security Expert INITiative
Proposal/Contract no.: IST-2002-001929-SEINIT
D3.1
Preliminary Implementation & Development Specification
Project Document Number: SEINIT/D3.1/PU/v0 (official version)
Project Document Date: 26/05/2004
Workpackage Contributing to the Project Document: WP3
Deliverable Type and Security: R-PU
Author(s): WP3
Abstract:
D3.1 is the first document of Work Package 3 (WP3) named Implementation of Components and Models.
This document is the report on preliminary implementation and development specification.
Components are distributed in 4 tasks:
- T3.1: Enhancements to IPv6 security mechanisms and v4-v6 transition mechanism,
- T3.2: Additional mobility support,
- T3.3: Supplementary Access Control functionality for Mobility,
- T3.4: Preliminary implementations to secure E2E service architecture.
For each component provided by the WP3 tasks, D3.1 document includes a description of the pre-existing
components, explaining their purpose, how they will be used or adapted and how they will interoperate with
the other components of the project. For new components needed and developed by the project, the
document specifies the required behaviour and interfaces.
Keywords: WP3, Components, Models, interfaces
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 1 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
History
Version
Date
Description, Author(s), Reviser(s)
0.1
07/04/2004
Document creation - P. Reymond (ALCA)
0.2
16/04/2004
Addition of sections DNSsec, Policy Management, CGA, Access Control
Infrastrucuture (AAA, PKI, Privilege Management Infrastructure, SAML, PANA)
- Antonio F. Gómez Skarmeta (UMU)
0.3
26/04/2004
Access Control managed with Credentials (SAML) - Antonio F. Gómez Skarmeta
(UMU)
0.4
28/04/2004
Template update - T. Legras (ALCA)
0.5
12/05/2004
Addition of section : IPSEC enhancements, Return Routeability, EAP - Gerhard
Gessler, Wolfgang Fritsche (IABG)
Addition of section : Security for IPv4/IPv6 transition mechanism, Return
Routeability, IPSec state of art in Alcatel - P. Reymond (ALCA)
Addition of section : Adaptative Contents in E2E security mechanisms chapter Arnaud Pierre, Frédérique Tastet (THC)
Addition of section : IP Signalling in E2E security mechanisms chapter Sandrine Masson, Vincent Maury, Frédérique Tastet (THC)
Addition of section on Honeypot - Maxime Feroul (KYOS)
0.6
14/05/2004
Addition to section on Honeypots - Wireless Honeypots, Steven Davy, John
Ronan (WIT)
Addition of Section: Snort IPv6 and Wireless IDS - Steven Davy, John Ronan
(WIT), Bruno Blumenthal (TELS)
0.7
24/05/2004
Modifications after Audio conference review 18/05/2004:
•
Transition Mechanism - P. Reymond (ALCA)
•
IPSEC enhancements - Gerhard Gessler (IABG)
•
Overall document organization - Thierry Legras (ALCA)
•
Dynamic IPv6 Honeypot - Maxime Feroul (KYOS)
Addition of section: Purpose & scope - Thierry Legras (ALCA)
Addition of sections: Routing Security, Distributed Infrastructures - Jordane
Hurier, Frédérique Tastet (THC)
0.8
26/05/2004
Modifications on NAT-PT in 2.1.3 and 2.1.5 chapter – P. Reymond (ALCA)
Minor modifications after final review – T. Legras (ALCA)
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 2 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
SEINIT Partners
Participant Name,
Short
Address & Web Site
Thales Communications S.A.
160, bld de Valmy, 92704 COLOMBES , FRANCE
www.thales-communications.com
ALCATEL S.A.
54, rue La Boétie, 75008 Paris, FRANCE
www.alcatel.com
British Telecom plc
81 Newgate Street, LONDON EC1A 7AJ, UNITED KINGDOM
www.bt.com
T-Systems Nova GmbH
Am Probsthof 10, 53121 BONN, GERMANY
www.t-systems.com
Groupe des Ecoles des Télécommunications - Ecole Nationale Supérieure des Télécommunications
(GET-ENST)
46, rue Barrault, 75634 PARIS, FRANCE
www.enst.fr
Industrieanlagen-Betriebsgesellschaft mbH (IABG)
Einsteinstrasse 20, 85521 OTTOBRUNN, GERMANY
www.iabg.de
KYOS SARL,
89, rue de la Servette, GENEVE, SWITZERLAND
www.kyos.ch www.kyos.ch
TELSCOM AG
Aarwilweg 20, 3074 MURI, SWITZERLAND
www.telscom.ch
Thales Research and Technology (UK) Limited
Dashwood Lang Road, Bourne Business Park, WEYBRIDGE KT15 2NX, UNITED KINGDOM
www.trt.uk
University College London
Gower Street, WC1E 6BT LONDON, UNITED KINGDOM
www.cs.ucl.ac.uk
Universidad de Murcia
Av. Teniente Flomesta s/n, 30001 MURCIA, SPAIN
www.um.es
Waterford Institute of Technology
Cork road, WATERFORD, IRELAND
www.tssg.org
Internet Society (ISOC)
4, rue des Falaises, 1205 GENEVE, SWITZERLAND
www.isoc.org
Name
THC
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
ALCA
BT
DT
ENST
IABG
KYOS
TELS
TRT
UCL
UMU
WIT
ISOC
Page 3 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Contents
Page
1
Introduction ............................................................................................................................ 8
1.1
1.2
1.3
1.4
2
Enhancements to IPv6 security mechanisms and v4-v6 transition mechanisms................... 11
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.5
2.5.1
2.5.2
2.5.3
2.5.4
2.5.5
2.6
2.6.1
2.6.2
2.6.3
2.6.4
2.6.5
3
Purpose and scope ...................................................................................................................... 8
Structure ..................................................................................................................................... 8
Definition .................................................................................................................................... 8
Abbreviation ............................................................................................................................... 9
Security for IPv4/IPv6 transition mechanisms .........................................................................11
Generalities...........................................................................................................................................11
Functional description ...........................................................................................................................11
State of art.............................................................................................................................................17
Purpose in SEINIT ................................................................................................................................19
Adaptation and use ................................................................................................................................20
Interaction with other components .........................................................................................................21
DNSsec .......................................................................................................................................22
Functional description ...........................................................................................................................22
State of art.............................................................................................................................................22
Purpose in SEINIT ................................................................................................................................23
Adaptation and use ................................................................................................................................23
Interaction with other components .........................................................................................................23
IPv6 routing security .................................................................................................................23
Functional description ...........................................................................................................................23
State of art.............................................................................................................................................24
Purpose in SEINIT ................................................................................................................................24
Adaptation and use ................................................................................................................................24
Interaction with other components .........................................................................................................25
IPsec enhancements ...................................................................................................................25
Functional description ...........................................................................................................................25
State of art.............................................................................................................................................25
Purpose in SEINIT ................................................................................................................................26
Adaptation and use ................................................................................................................................26
Interaction with other components .........................................................................................................27
Mobility in secure architectures (Return Routeability)............................................................27
Functional description ...........................................................................................................................27
State of art.............................................................................................................................................29
Purpose in SEINIT ................................................................................................................................29
Adaptation and use ................................................................................................................................29
Interaction with other components .........................................................................................................29
Access Control managed with CGA..........................................................................................29
Functional description ...........................................................................................................................29
State of art.............................................................................................................................................30
Purpose in SEINIT ................................................................................................................................30
Adaptation and use ................................................................................................................................30
Interaction with other components .........................................................................................................30
Supplementary Access Control functionality ........................................................................ 31
3.1
Access Control Infrastructure...................................................................................................31
3.1.1 AAA .....................................................................................................................................................31
3.1.1.1
Functional description...................................................................................................................31
3.1.1.2
State of art ....................................................................................................................................31
3.1.1.3
Purpose in SEINIT........................................................................................................................32
3.1.1.4
Adaptation and use........................................................................................................................32
3.1.1.5
Interaction with other components.................................................................................................32
3.1.2 PKI .......................................................................................................................................................33
3.1.2.1
Functional description...................................................................................................................33
3.1.2.2
State of art ....................................................................................................................................33
3.1.2.3
Purpose in SEINIT........................................................................................................................34
3.1.2.4
Adaptation and use........................................................................................................................34
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 4 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
3.1.2.5
Interaction with other components.................................................................................................34
3.1.3 Privilege Management Infrastructure .....................................................................................................34
3.1.3.1
Functional description...................................................................................................................34
3.1.3.2
State of art ....................................................................................................................................35
3.1.3.3
Purpose in SEINIT........................................................................................................................35
3.1.3.4
Adaptation and use........................................................................................................................36
3.1.3.5
Interaction with other components.................................................................................................36
3.1.4 Security Assertion Markup Language(SAML) .......................................................................................36
3.1.4.1
Functional description...................................................................................................................36
3.1.4.2
State of art ....................................................................................................................................36
3.1.4.3
Purpose in SEINIT........................................................................................................................36
3.1.4.4
Adaptation and use........................................................................................................................36
3.1.4.5
Interaction with other components.................................................................................................37
3.1.5 Protocol for Carrying Authentication for Network Access (PANA) ........................................................37
3.1.5.1
Functional description...................................................................................................................37
3.1.5.2
State of art ....................................................................................................................................37
3.1.5.3
Purpose in SEINIT........................................................................................................................37
3.1.5.4
Adaptation and use........................................................................................................................37
3.1.5.5
Interaction with other components.................................................................................................38
3.2
Access Control managed with Credentials ...............................................................................38
3.2.1 EAP Keying Framework........................................................................................................................38
3.2.1.1
Functional description...................................................................................................................38
3.2.1.2
State of art ....................................................................................................................................39
3.2.1.3
Purpose in SEINIT........................................................................................................................39
3.2.1.4
Adaptation and use........................................................................................................................39
3.2.1.5
Interaction with other components.................................................................................................39
3.2.2 SAML Access Control...........................................................................................................................40
3.2.2.1
Functional description...................................................................................................................40
3.2.2.2
State of art ....................................................................................................................................40
3.2.2.3
Adaptation and use........................................................................................................................40
3.2.2.4
Interaction with other components.................................................................................................40
4
Preliminary implementations to secure E2E service architectures ....................................... 41
4.1
E2E security mechanisms..........................................................................................................41
4.1.1 Distributed infrastructures .....................................................................................................................41
4.1.1.1
Functional description...................................................................................................................41
4.1.1.2
State of art ....................................................................................................................................41
4.1.1.3
Purpose in SEINIT........................................................................................................................42
4.1.1.4
Adaptation and use........................................................................................................................42
4.1.1.5
Interaction with other components.................................................................................................42
4.1.2 Adaptive content ...................................................................................................................................42
4.1.2.1
Functional description...................................................................................................................42
4.1.2.2
State of art ....................................................................................................................................42
4.1.2.3
Purpose in SEINIT........................................................................................................................43
4.1.2.4
Adaptation and use........................................................................................................................43
4.1.2.5
Interaction with other components.................................................................................................44
4.1.3 QoS.......................................................................................................................................................44
4.1.3.1
State of the art status of flowlabel definition ..................................................................................44
4.1.3.2
Network Architecture....................................................................................................................44
4.1.3.3
IPv6 Flow Label Specification.......................................................................................................45
4.1.3.4
Security issues related with the use of Flow label...........................................................................46
4.1.3.5
SEINIT relevance .........................................................................................................................47
4.1.4 Policy management ...............................................................................................................................47
4.1.4.1
Functional description...................................................................................................................47
4.1.4.2
State of art ....................................................................................................................................48
4.1.4.3
Purpose in SEINIT........................................................................................................................48
4.1.4.4
Adaptation and use........................................................................................................................49
4.1.4.5
Interaction with other components.................................................................................................49
4.2
Honeypot....................................................................................................................................49
4.2.1 Dynamic IPv6 honeypot ........................................................................................................................49
4.2.1.1
Functional description...................................................................................................................49
4.2.1.2
State of art ....................................................................................................................................51
4.2.1.3
Purpose in SEINIT........................................................................................................................52
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 5 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
4.2.1.4
Adaptation and use........................................................................................................................52
4.2.1.5
Interaction with other components.................................................................................................52
4.2.2 Wireless Honeypots...............................................................................................................................53
4.2.2.1
Functional description...................................................................................................................53
4.2.2.2
State of art ....................................................................................................................................53
4.2.2.3
Purpose in SEINIT........................................................................................................................53
4.2.2.4
Adaptation and use........................................................................................................................53
4.2.2.5
Interaction with other components.................................................................................................53
4.3
IDS .............................................................................................................................................53
4.3.1 Snort v6 and wireless IDS......................................................................................................................53
4.3.1.1
Functional Description ..................................................................................................................53
4.3.1.2
State of the Art..............................................................................................................................54
4.3.1.3
Purpose in SEINIT........................................................................................................................54
4.3.1.4
Adaptation and use........................................................................................................................54
4.3.1.5
Interaction with other components.................................................................................................55
5
Reference .............................................................................................................................. 56
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 6 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Figures
Figure 1: DSTM communications ...............................................................................................................12
Figure 2: Communication though manually configured tunnel.....................................................................13
Figure 3: 6to4 address.................................................................................................................................13
Figure 4: Communication between two 6To4 sites ......................................................................................14
Figure 5: Communication between a 6To4 and a native IPv6 site ................................................................14
Figure 6: ISATAP address ..........................................................................................................................15
Figure 7: ISATAP address allocation ..........................................................................................................15
Figure 8: NAT-PT communication from v6 to v4 ........................................................................................16
Figure 9: Teredo address.............................................................................................................................17
Figure 10: NAT-PT in SEINIT global architecture ......................................................................................21
Figure 11: Integration of DNSSEC and the UMU-PKIv6 ............................................................................22
Figure 12: Overview of the return routability process ..................................................................................28
Figure 13: UMU-PKIv6 components...........................................................................................................34
Figure 14: UMU-PMIv6 components ..........................................................................................................35
Figure 15: EAP overview............................................................................................................................38
Figure 16: SAML example..........................................................................................................................40
Figure 17: Detailed Architecture of a generic CAM.....................................................................................43
Figure 18: IPv6 network with QoS options..................................................................................................45
Figure 19: General View of the UMU-PBNM Architecture .........................................................................48
Figure 20: How Honeyd Works...................................................................................................................51
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 7 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
1 Introduction
1.1 Purpose and scope
For each component provided by the Work Package 3, this document includes a description of the preexisting components, explaining their purpose, how they will be used or adapted and how they will
interoperate with the other components of the project.
The first version of the document focus on the description of the preexisting components and gives some first
use cases for SEINIT.
A second version will be further delivered when SEINIT architecture will be completed in Work Package 2.
It will complete the sections related to existing components interfaces and adaptation for seinit; in addition it
will include the new components behavior and their interface description as well.
1.2 Structure
The components are classified into four sections:
• Enhancements to IPv6 security mechanisms and v4-v6 transition mechanisms
•
•
Supplementary Access Control functionality
Preliminary implementations to secure E2E service architectures
For each component the following information is detailed:
• Functional description
• State of art
• Purpose in SEINIT
• Adaptation and use
• Interaction with other components
1.3 Definition
Transition Mechanisms
DSTM Domain: the network areas on an Intranet where a DHCPv6 Server has access to IPv6 nodes
participating in DSTM for that network, and where IPv4 routing access is not necessary.
DSTM Border Router: a border router that accesses a DSTM domain and an IPv4-only cloud.
DSTM Host: a dual-stack host with DTI and DHCPv6 client processes.
DTI: a Dynamic tunneling interface, that encapsulates IPv4 packets into IPv6 packets.
TEP: the tunnel end point is the destination of IPv6 packets containing an IPv4 packet. In most cases, this
will be the DSTM border router.
6to4 host: it is an IPv6 host that has at least one 6to4 IP address.
6to4 router(or 6to4 border router): it is an IPv6 router supporting the 6to4 addressing. It is normally the
border router between an IPv6 site and a wide-area IPv4 network.
6to4 relay router: it is a router configured to support transit routing between 6to4 addresses and native IPv6
addresses.
Mobility
care-of address (CoA): Corresponds to a “unicast routable address associated with a mobile node while
visiting a foreign link”. A Mobile may have multiple care-of addresses at any given time (e.g., for different
subnet prefixes), the one registered with the mobile node's home agent for a given home address is called its
"primary" care-of address.
Home address: The static IP address allocated to a mobile node. It does not change (except home
address prefix expiration or replacement), no matter where the node accesses to the network from.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 8 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Home agent: A router on the home network of the mobile node that maintains current location
information for the node (CoA) and tunnels datagrams for delivery to the node when it is away from
home.
Correspondent Node: A host or a router sending packets to the Mobile Node.
Mobile Node: Host which is changing of sub-network. (ex: From Home Network to any other kind of
network).
IP Security
Security Association (SA): A Security Association is a one-way relationship between a sender and a
receiver that applies security services to the traffic carried on it. If a peer relationship is needed for two-way
secure exchange then two Security Associations are required.
Security Association Database (SAD): The Security Association Database is the collection of parameters
associated with SAs. Each SA has an entry in the SAD, specifying all the things necessary to perform IPsec
processing for the IP packet belonging to the SA.
Security Policy Database (SPD): The Security Policy Database contains the Security Policy requirements
established and maintained by a user or system administrator, or by an application operating within the
constraints established by either of the above. An SPD entry has two components, a set of selectors and an
action. The selectors map an IP packet onto an action. There are three possible actions: apply IPsec security
service, discard the IP packet or allow the IP packet to bypass IPsec processing. If the selected action is to
apply the IPsec security service, the details of the service (e.g. 3DES encryption and SHA-1 authentication)
are also stated in the policy entry.
Tunnel Mode SA: A Tunnel Mode SA is a Security Association between two hosts, a host and a security
gateway, or two security gateways. The original IP packet is encapsulated in another IP packet and then,
depending on the applicable SPD and SAD entries, ESP and / or AH is employed.
Transport Mode SA: A Transport Mode SA is a Security Association between two hosts. In the original IP
packet, depending on the applicable SPD and SAD entries, ESP and / or AH is employed.
ISAKMP SA: The ISAKMP Security Association is established between two IKE instances which agree on
how to protect further communication between them. Although called an SA, an ISAKMP SA is not to be
confused with an IPsec SA. An ISAKMP SA is bi-directional and does not actually apply to the IPsec traffic.
Protocol SA / IPsec SA: The IPsec Security Association is established between two IKE instances which
agree on how to protect further IP communication between the hosts or security gateways which they run on.
IPsec SAs are only uni-directional and are only applied to the IP traffic.
1.4 Abbreviation
AH
Authentication Header
DA
Destination Address
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
DSTM Dual Stack Transition Mechanism
DTI
Dynamic Tunneling Interface
E2E
End to End
EGP Exterior Gateway Protocol
ESP Encapsulation Security Payload
FTP
File Transfer Protocol
GUI
Graphical User Interface
IKE
Internet Key Exchange
IP
Internet Protocol
IPSec Internet Protocol Security
ISAKMP Internet Security Association and Key Management Protocol
ISATAP Intra-Site Automatic Tunnel Addressing Protocol
ISP
Internet Service Provider
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 9 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
MIB
Management Information Base
MP-BGP Multi Protocol BGP
NAPT-PT Network Address Port Translation-Protocol Translation
NAT-PT Network Address Translation-Protocol Translation
NLRI Network Layer Reachability Information
PKI
Public Key Infrastructure
PSK Pre-Shared Secret
RA
Router Advertisement
RFC Request For Comments
RR
Resource Record
RS
Router Solicitation
RSA Public-Key cryptography system for encryption and authentication (its name is derived from
the surnames of the three inventors Rives, Shamir, and Adleman)
SA
Security Association
SAD Security Association Database
SIIT
Stateless IP/ICMP Translation Algorithm
SPD Security Policy Database
TCP Transmission Control Protocol
TEP
Tunnel End Point
TLA
Top Level Aggregator
UDP User Datagram Protocol
VPN Virtual Private Network
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 10 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
2 Enhancements to IPv6 security mechanisms and v4-v6
transition mechanisms
2.1 Security for IPv4/IPv6 transition mechanisms
2.1.1 Generalities
The IPv4/IPv6 transition methods can be divided to:
- dual IPv4/IPv6 stack: it is specified in RFC 2893 updated in draft-ietf-v6ops-mech-v2-02.txt
- tunneling : Tunneling is a transition mechanism that requires dual IPv4/IPv6 stack functionality in the
encapsulating and decapsulating nodes. Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6.
Tunneling can be static or dynamic. Static (configured) tunnels are fixed IPv6 links over IPv4, and they are
specified in [RFC2893] and updated in draft-ietf-v6ops-mech-v2-02.txt. Dynamic (automatic) tunnels are
virtual IPv6 links over IPv4 where the tunnel endpoints are not configured, i.e. the links are created
dynamically.
- protocol translators: A translator can be defined as an intermediate component between a native IPv4
node and a native IPv6 node to enable direct communication between them without requiring any
modifications to the end nodes. Header conversion is a translation mechanism. In header conversion, IPv6
packet headers are converted to IPv4 packet headers, or vice versa, and checksums are adjusted or
recalculated if necessary. NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] using
SIIT [RFC2765] is an example of such a mechanism. Translators may be needed in some cases when the
communicating nodes do not share the same IP version; in others, it may be possible to avoid such
communication altogether. Translation can actually happen at Layer 3 (using NAT-like techniques), Layer 4
(using a TCP/UDP proxy) or Layer 7 (using application relays).
There are 2 types of scenarios:
- Communication between IPv6 islands via IPv4 clouds: Configured and automatic Tunneling, 6to4
Tunneling, ISATAP
- Communication between existing IPv4 and IPv6 clouds: DSTM, NAT-PT, SIIT
The ngtrans IETF working group status was concluded in Febrary 2003. The v6ops IETF working group is
now responsible for advancing the basic IPv6 transition mechanism RFCs: Transition Mechanisms (RFC
2893), SIIT (RFC 2765), NAT-PT (RFC 2766), 6to4 (RFC 3056 & 3068). The applicability of many valid
methods currently are not in v6ops working group chapter like DSTM, ISATAP and Teredo.
2.1.2 Functional description
DSTM
DSTM is dual IPv4/IPv6 stack. It is targeted to help the interoperation of IPv6 newly deployed networks
with existing IPv4 networks. DSTM only really works from IPv6 cloud to IPv4 cloud. DSTM purpose is to
provide to IPv6 nodes a global IPv4 address, for communication with IPv4-only nodes or IPv4 applications.
It provides :
- a method to assign temporary global IPv4 address to dual stack nodes over a native IPv6 site. This v4
address is taken from a pool of available addresses defined at the DSTM domain level.
- a method to create dynamic tunnels to carry IPv4 traffic over an IPv6 network
- a defined set of processes and architecture for the supporting infrastructure.
In the following figure, the new DHCPv6 option is represented and provides Tunnel End Point to DSTM
hosts. A custom DHCPv6 server must implement the mechanisms needed to maintain the related
configuration information. DSTM hosts should implement the DTI mechanism, which needs a DHCPv6
client for IPv4 address and TEP retrieval. Otherwise, DHCP could be replaced by a RS/RA mechanism to get
an address.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 11 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
The DSTM host named A initiates an IPv4 communication with B. DSTM Host “A” queries its DNSv6 for
an A resource record for “B”. The DNS answers and gives the IPv4 address of “B”.
The application running on DSTM host “A” sends the IPv4 packet which is directed to the DTI interface.
Since it’s the first use of the DTI, A needs a temporary v4 address and queries the DHCPv6 server for one.
The DHCPv6 server locates the client and provides him a temporary IPv4 global address, and advertises the
DSTM border router address as the TEP address.
The IPv4 packet is encapsulated in an IPv6 packet, which destination is the TEP.
The router decapsulates the IPv6 packet and sends its IPv4 content to B. It also caches the association
between both v4 and v6 addresses of DSTM host “A”.
Host “B” receives the packet. It then responds with a packet which destination is the IPv4 address allocated
to A.
The packet from B reaches the DSTM Border router. As the IPv4 destination address is associated with an
IPv6 address, the router tunnels the IPv4 packet over IPv6 to host A.
The DTI interface decapsulates the IPv6 packet and forwards the IPv4 content to the Application Layer.
IPv6
IPv4
V4@
DHCP6+
A DSTM Host
Dual stack
DNS
DNS
DSTM Border router
B
Figure 1: DSTM communications
Manually Configured tunnel
Manually Configured tunnel is a static tunneling transition method. This transition mechanism is equivalent
to a permanent link between two IPv6 domains over an IPv4 backbone. At each end of the tunnel, you
configure the IPv4 and IPv6 addresses of the dual-stack router on the tunnel interface. Each tunnel exists
between only two routers and is independently managed.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 12 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Dual stack router
Dual stack router
IPv4 cloud
Ipv6 cloud
IPv6 cloud
IPv6
IPv6
Host AA
Host
R1
Tunnel: IPv6
in IPv4 packet
IPv4
SAv4 = R1
IPv4
Header
DAv4 = R2
IPv6
SAv6 = A
DAv6 = B
IPv6
IPv6
Host B
Host
A
R2
IPv6
SAv6 =A
IPv6
Header
IPv6
SAv6 = A
IPv4
Payload
DAv6 = B
DAv6 =B
IPv6 Payload
IPv6 Payload
IPv6 Payload
traffic
Figure 2: Communication though manually configured tunnel
6to4
6to4 is an automatic tunneling transition method. Specific IPv6 addresses are needed for 6to4 and it is used
by 6to4 host, 6to4 router and 6to4 relay.
According to [RFC3056], the format of 6to4 prefix, defined by IANA, is illustrated as follows:
3 bits
FP 001
13 bits
TLA 0x0002
32 bits
IPv4 Addr
16 bits
SLA ID
64bits
Interface ID
Figure 3: 6to4 address
The 6to4 prefix 2002:IPv4::/48 can be advertised by 6to4 router as any other valid IPv6 prefix, for automatic
address assignment and discovery mechanisms and for native IPv6 routing. A 6to4 address is considered as a
global address and DNS resource records may be defined with it.
There are 2 main scenarios:
- communication between two 6to4 sites
- communication between a 6to4 and a native IPv6 site
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 13 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
In the first scenario, two 6to4 hosts are separated by an IPv4 cloud. Each site identifies a router to run Dual
Stack (R1 and R2) and 6to4 tunneling, ensuring both have global routable IPv4 addresses. A router-to-router
tunnel will then be created between them.
Firstly, host A wishes to send an IPv6 packet to host B. The default route of prefix 2002::/16 is R1, therefore
A forwards the packet to R1.
As the IPv6 packet destination has a 6to4 address, R1 adds an IPv4 header which destination address is
derived from 6to4 address of B (in this case, that is the IPv4 address of R2) to the IPv6 packet and sends the
datagram to R2. The source IPv4 address will be R1.
R2 receives the IPv4 packet, recognizes the Protocol field value of 41, so applies IPv4 security checks, then
removes the IPv4 header. R2 looks at the destination and sends the packet to B.
6to4 Dual Stack
Router R1
6to4 Dual Stack
Router R2
6to4 site
6to4 site
IPv4 Cloud
IPv6
Host A
Native IPv6
traffic
IPv6
IPv6 packets
encapsulated in
IPv4 packets
Native IPv6 Host
traffic
B
Figure 4: Communication between two 6To4 sites
In the second scenario, such a communication pattern requires the use of 6to4 relay routers, as shown on the
following figure. The 6to4 relay router advertises a route to 2002::/16 into the native infrastructure. The
native IPv6 network operators must filter out and discard any 6to4 prefix advertisement longer than /16. On
its 6to4 connection, the relay router advertises whatever native IPv6 routes its policies allows. The 6to4
router gets informed of these routes with either an EGP (as MP-BGP), or with a default route to the 6to4
relay.
6to4 Dual Stack
Relay Router
6to4 Dual Stack
Router
6to4 site
6to4 site
IPv4 Cloud
IPv6
Host A
Native IPv6
traffic
Native IPv6
traffic
IPv6 packets
encapsulated in
IPv4 packets
Native IPv6
traffic
Native IPv6 Site
IPv6
Host B
Figure 5: Communication between a 6To4 and a native IPv6 site
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 14 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
ISATAP
ISATAP is an automatic tunneling transition method to connect IPv6 hosts/routers over an IPv4 Network.
An ISATAP address format is compatible with 6to4 and is as follows:
3
FP
13
8
TLA ID
RES
24
NLA ID
16
SLA ID
32 bits
32
0000 5EFE
IPv4 Address
Identifies an ISATAP address
Figure 6: ISATAP address
The following schema shows how a node configures ISATAP addresses.
IPv4
IPv6
ISATAP Router
R3
A
R2
B
R1
Figure 7: ISATAP address allocation
Firstly, the node B constructs an ISATAP link local address for itself : fe80::0:5EFE:B4
The node B gets the IPv4 address of the ISATAP router (R2) from DNS; ISATAP adding a new RR for
DNS.
Then, node B sends a RS to the IPv6 “all-routers-multicast” address tunneled through the IPv4 infrastructure
to the ISATAP router’s IPv4 address. The addresses used in the IPv6 and IPv4 headers are:
SAv4 = B4
DAv4 = R2-4
SAv6 = PREFIX::0:5EFE:B4
DAv6 = FF02::2
Upon receiving the tunneled RS, the ISATAP router sends a unicast RA to B by tunneling the RA through
IPv4. This RA advertises a PREFIX::/64. PREFIX is any routable prefix that the network administrator
chooses. The addresses used in the IPv6 and IPv4 headers are:
SAv4 = R2-4
DAv4 = B4
SAv6 = PREFIX::0:5EFE:R2-4
DAv6 = PREFIX::0:5EFE:B4
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 15 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Upon receiving the RA, the node creates a non link-local address, PREFIX::0:5EFE:B4/64. It also creates a
default route that points to the ISATAP router.
NAT-PT
NAT-PT (Network Address Translation - Protocol Translation) is described in [RFC2766].
The prefix PREFIX::/96 is advertised in the stub domain, and packets addressed to this PREFIX will be
routed to the NAT-PT (R2). PREFIX is any routable prefix that the network administrator chooses.
Each NAT-PT device retains a pool of globally routable IPv4 addresses which are used to be assigned to
IPv6 nodes on a dynamic basis as sessions are initiated across the IPv6/IPv4 boundary.
The basic NAT-PT translation device may additionally contain ALGs. For some applications where IP
addresses may be embedded within the payload, an ALG is necessary to look inside the payload and translate
those IP addresses. A DNS-ALG is an essential part of NAT-PT but other ALGs can be provided such as
FTP-ALG.
-When the communication is initiated by an IPv6 host A:
IPv6 host sends a packet with SA= A6 and DA=PREFIX:B4. The router NAT-PT receives the packet and
translates header v6 into header v4 using SIIT partly. Destination address v6 is translated into v4 address
removing PREFIX. Source address v6 is translated in v4 Address finding corresponding address in the pool.
Indeed, when translating the AAAA response into an A response, the NAT-PT device needs to allocate an
IPv4 address from the pool and create a mapping between this IPv4 address and the IPv6 address of host A.
- When the communication is initiated by an IPv4 host B:
IPv4 host sends an A request to DNS server v4 D2 on IPv6 host name. The request is forwarded to DNS
server v6 D1 via router NAT sending AAAA request. Router NAT R2 translates A request into AAAA
request using DNS-ALG. The answer from IPv6 DNS Server is forwarded to the IPv4 DNS Server via router
NAT which translate AAAA reply into A reply. Now IPv4 host is able to send an IPv4 packet to IPv6 host
via NAT router which translates header using SIIT partly.
IPv6
IPv4
D1
A
D2
R2
R1
R3
B
Figure 8: NAT-PT communication from v6 to v4
Teredo
Teredo, also known as IPv4 network address translator (NAT) traversal for IPv6, is a protocol translator that
provides address assignment and host-to-host automatic tunneling for unicast IPv6 connectivity when
IPv6/IPv4 hosts are located behind one or multiple IPv4 NATs. To traverse IPv4 NATs, IPv6 packets are
sent as IPv4-based User Datagram Protocol (UDP) messages.
Teredo communication is facilitated by Teredo servers and Teredo relays. A Teredo host-specific relay is an
IPv6/IPv4 host that does not use Teredo addresses, but can communicate with Teredo clients without having
to use a Teredo relay in the communication path.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 16 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
There are defined processes for obtaining a Teredo address, maintaining a NAT mapping, and performing
initial communications between Teredo clients, Teredo host-specific relays, and IPv6-only hosts. The initial
communication process in each case depends on whether the Teredo client is located behind a cone or
restricted NAT.
A cone NATs is a NAT in which the NAT translation table entry stores a mapping between an internal
address and port number and an external address and port number. Once the NAT translation table entry is in
place, inbound traffic to the external address and port number from any source address and port number is
translated.
A restricted NATs is NAT in which the NAT translation table entry stores a mapping between an internal
address and port number and an external address and port number, for either specific source addresses or
specific source address and port numbers. An inbound packet that matches the NAT translation table entry
for the external destination address and port number from an unknown external address or port number is
silently discarded.
The Teredo addresses are the following format:
Prefix
32 bits
Server IPv4
32 bits
Flags
16 bits
Port
16 bits
Client IPv4
3 bits
Figure 9: Teredo address
- Prefix: the 32 bit Teredo service prefix which is the same for all Teredo addresses. The Internet Assigned
Numbers Authority (IANA) has not yet defined this prefix.
- Server IPv4: the IPv4 address of a Teredo server contains the IPv4 public address of the Teredo server that
helped configure this Teredo address
- Flags: one flag defined is Cone flag which is set when the NAT connected to the Internet is a cone NAT.
The determination of whether the NAT connected to the Internet is a cone NAT occurs during the Teredo
client's initial configuration,
- Port: the obfuscated "mapped UDP port" of the Teredo service at the client
- Client IPv4: the obfuscated "mapped IPv4 address" of a client
2.1.3 State of art
DSTM
The last draft of DSTM is draft-ietf-ngtrans-dstm-07 and it has expired. Unfortunately DSTM is not yet
included in the v6ops charter, but there seems to be a reasonable deployment case for the technique, namely
an IPv6-only network with dual-stack hosts where translation techniques are not desirable for IPv4 access.
ENST, within the scope of RENATER in France, is the principal architect of DSTM, has contributed
significantly to the IETF ngtrans working group, and made a DSTM implementation available and tested
under Freebsd 4.3 and Linux.
There is not yet Windows implementation of DSTM, which is one platform where the technique would
potentially be most often required.
For these reasons explained above, DSTM is not selected in SEINIT project.
Configured tunnel
Configured tunnel is described in RFC2893: Transition Mechanisms for IPv6 Hosts and Routers. RCF2893
is being updated by draft-ietf-v6ops-mech-v2-02.txt.
In Kame Implementation, GIF (Generic InterFace) is a pseudo interface for configured tunnel. GIF covers
"configured tunnel" described in the RFC2893.
Alcatel implemented configured tunnel on Alcatel 7770 (now discontinued) which has been demonstrated at
ETSI IPv6 plug test.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 17 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
6to4
6to4 is described in RFC3056: Connection of IPv6 Domains via IPv4 Clouds called "6to4".
Kame implementation supports RFC3056.The pseudo interface "stf" implements it, see draft-itojun-ipv6transition-abuse-01.txt below before configuring it. Security issues are specifically considered in draft-ietfv6ops-6to4-security-02.txt written in March 2004.
ISATAP
- The last draft of ISATAP is in draft-ietf-ngtrans-isatap-21. It is as not yet been adopted by the IETF v6ops
working group.
- Linux implementation: Linux hosts can be used both as ISATAP servers and clients. For both uses ISATAP
functionality has to be added to the kernel along with the iproute2 package. Due to its on going
standardization process ISATAP has not yet been merged into the standard kernel. Therefore it has to be
added manually. USAGI has been developing IPv6 support for Linux for many years and includes ISATAP
in its kernel patches since 2002. The patches are available on FTP server,
- Cisco implementation: (Dualstack-)Cisco routers with an ISATAP supporting IOS version can be
configured as ISATAP servers. For that a tunnel interface has to be configured specifying the special tunnel
mode ipv6ip isatap,
- 6Wind implementation: Setting up a 6WIND machine (6WIND-Gate) as an ISATAP router is rather easy
and is mainly achieved with only two commands on CLI (Command Line Interface). This is structured in
different sections and subsections quite similar to for example the Cisco IOS,
- Windows XP dropped 6over4 support that was present in Windows 2000 and replaced it with ISATAP for
host and router,
- UNINETT is testing an ISATAP deployment under Linux, having deployed an ISATAP router. DFN is
also deploying ISATAP, so there are now multiple ISATAP routers within 6NET, running both Cisco
(router) and Linux (host and router) implementations,
- Kame implementation: ISATAP was implemented in January 2003 but was removed due to IPR issue,
- ISATAP is not selected for SEINIT project because v6ops does not maintain it and there is an Intellectual
Property Rights restriction.
NAT-PT
- As well as co-authoring the original standard for NAT-PT, BT Exact has implemented the most functional
version of the mechanism in its 'Ultima' interworking device. Ultima is installed and operational as part of
the UK6x IPv6 Internet Exchange point in London. The Ultima NAT-PT implementation was rigorously and
succesfully tested as part of the IPv6 network deployment for the IETF51 meeting in London. Within 6NET,
ULB is running the Ultima NAT-PT on a FreeBSD PC across the border of an IPv6-only network and the
Internet. The Ultima NAT-PT also has a tunnel to the native IPv6 network. MClab has also set up NAT-PT
at its site and some cooperative testing between the two sites has been successfully carried out. Southampton
University has also been running NAT-PT using the FreeBSD implementation from the KAME code. The
gateway has been used successfully to translate outbound IPv6 connections to IPv4, and vice-versa to allow
external IPv4 nodes to connect to IPv6 servers. UCL has been running a FreeBSD/KAME based NAT-PT
server on its IPv6 network. The gateway has been used successfully to translate outbound IPv6 connections,
from IPv6 only machines, to IPv4 servers.
- Ultima supports all the functionality specified in RFC2765 and RFC2766 as well as a DNS-ALG and a
proprietary tunneling mechanism. A flexible web-based management interface provides simplified
configuration of the address pool and DNS-ALG, as well as detailed reporting of operational statistics in
real-time.
- Kame supports SIIT [RFC2765] and part of RFC2766: Network Address Translation Protocol Translation
(NAT-PT). In RFC2766, the section 4.2 "V4 Address Assignment for Outgoing Connections (V6 to V4)" is
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 18 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
implemented by totd. But the Section 4.1 "V4 Address Assignment for Incoming Connections (V4 to V6)" is
not supported by Kame.
Teredo
The lastest draft is draft-huitema-v6ops-teredo-01.txt writen by C. Huitema (Microsoft). It will expire in
August 5.
There is no Teredo deployment in 6NET yet, but some partners are interested to do so when an
implementation becomes available, perhaps with IPv6 access for home users with IPv4 NAT over dial-up or
ADSL in mind,
It should be remembered that Teredo is presented as a “last resort” mechanism, and has yet to be adopted by
the IETF v6ops working group, so Teredo is not selected in SEINIT project.
MIPv6/MIPv4
There are two drafts expired concerning mobility and transition mechanism written within ngtrans working
group:
- draft-engelstad-ngtrans-6to4-v4v6-mobility-00.txt:
“This draft outlines how a 6to4-enabled host can be provided with transparent IPv4 and IPv6 connectivity
and mobility no matter if the host is located in a 6to4 network or is roaming an IPv4-only network.”,
- draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt:
“This draft outlines how a dual stack mobile node can be reached and communicate by means of both IPv4
and IPv6, even in situations where the mobile node is in reach of only either IPv4 or IPv6 networks. A Dual
Stack Mobility Agent accommodates mobility and translates between IPv4 and IPv6 traffic. It may operate
as a mobility agent in its own right or as a module that relays traffic between existing single stack Mobile
IPv4 and Mobile IPv6 home agents.”,
As these drafts have not been discussed in v6ops, we propose to leave this search subject out seeing that
mobility itself is still draft status.
2.1.4 Purpose in SEINIT
Configured tunnel
This kind of tunnel is used for sites whose architecture does not change often. The interest of the Configured
tunnel is that this mechanism doesn’t require specific features for the host. In SEINIT, we could:
- introduce IPSec in configured tunnelling to protect data in IPv4 cloud.
- apply the check defined in draft-ietf-v6ops-mech-v2-02 to avoid that attack is able to know the source of
the tunnel and is able to spoof it. The purpose of the check is to avoid that an attacker spoofs IPv6 addresses
inside the IPv4 tunnel, by making sure that only a trusted source (i.e. the other endpoint) can send
encapsulated traffic, and having these trusted sources applying regular anti-spoofing protections, such as
ingress filtering.
6to4
Concerning security aspect of 6to4, threats are sorted by : spoofing, direct attack, attack by reflection, others.
The threat use for attack 6to4 routers, 6to4 relays, any IPv6 nodes and any 6to4 nodes. We propose:
- to perform security checks of the 6to4 router describe in draft-ieft-v6ops-6to4-security-02.
- ingress filtering in the native IPv6 networks to prevent packets with spoofed IPv6 source being transmitted.
It would, thus, make it easy to identify the source of the attack.
NAT-PT
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 19 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
The benefit of NAT-PT is that this mechanism doesn’t require dual stack but it has limitation in security:
compatibility problem with IPSec and IKE. See draft-okazaki-v6ops-natpt-security-00.txt and draft-abobanat-ipsec-04 for security aspect (breaking end to end security, DoS when exhausting the address pool, …).
We could propose a component to keep end to end security though several scenarios.
2.1.5 Adaptation and use
Configured tunnel
Configured tunnel could be adapted and use in SEINIT to permit more security and avoid some attacks.
Modifications consist in:
•
inserting AH or ESP header to authenticate or encrypt payload in tunnel mode,
IPv6 Header
•
AH / ESP
IPv4 Header
Payload
adding the check defined in draft-ietf-v6ops-mech-v2-02 to avoid spoof attack :
o IPv4 source address of the packet MUST be the same as configured for the tunnel end-point,
o IPv4 ingress filtering MAY be implemented to check that the IPv4 packets are received from an
expected interface,
o IPv6 packets with several, obviously invalid IPv6 source addresses MUST be discarded,
o IPv6 ingress filtering should be performed, to check that the IPv6 packets are received from an
expected interface.
6to4
6to4 could be adapted in SEINIT to increase security for this transition mechanism adding these following
features described in draft-ieft-v6ops-6to4-security-02 :
• Disallow traffic that has private, broadcast or reserved IPv4 addresses in tunnels, or the matching 6to4
prefixes,
• Disallow traffic from 6to4 routers where the IPv4 tunnel source address does not match the 6to4 prefix,
• Disallow traffic where the destination IPv6 address is not a global address; in particular, e.g. link-local
addresses, mapped addresses and such should not be used,
• Disallow traffic transmission to other 6to4 domains through 6to4 relay router or via some third party
6to4 router,
• Discard traffic received from other 6to4 domains via a 6to4 relay router,
•
Discard traffic received for prefixes other than your own 6to4 prefix(es).
NAT-PT
NAT-PT could be adapted to :
• manage NAT-PT and IPSec incompatibilities, for example NAT-PT cannot translate IP Header if it is
protected by AH,
•
try to not break security.
Due to the incompability between AH and IKE with NAT, a component SEINIT could be able to detect a
presence of NAT and could notify to other SEINIT components that IPSec AH tunnel is not supported.
Indeed, if NAT is present, ESP in transport mode and manual keying will be used to protect data. If NAT is
not present, authentication, encryption and IKE will be applied. An alternative solution would be to view the
NAT-PT translator as a trusted security proxy, and mediate IPsec SAs as part of the translation function.
Such a solution would benefit from integration with security policy management and authorisation
credentials.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 20 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
SEINIT can implement bi-directional translation scenarios using the Ultima NAT-PT device.
2.1.6 Interaction with other components
Configured tunnel
A Part of information of packets could be transmitted to the SEINIT components of decision module.
6to4
Since the 6to4 router assumes all the other 6to4 routers, and 6to4 relays are "on-link" it is possible to attack
the 6to4 router using ND messages from any node in the IPv4 network, unless a prior trust relationship has
been established. We could use SEND to protect 6to4 router against such attack.
NAT-PT
The NAT-PT adapted for SEINIT is well included in decision global architecture modules. NAT router gives
information “ NAT not compatible with IKE/NAT ” to decision module. The decision module takes a
decision following the logic rule: if NAT enabled then do ESP transport mode and manual keying if NAT
disabled then do AH ESP and IKE. Decision taken is sent to action module to apply chosen mechanisms.
DECISION module
ACTION
ACTION
INFORMATION
Use ESP, transport mode
Use manual keying
Use ESP, transport mode
Use manual keying
“device not compatible
with IKE nor AH”
Host
Host
NAT-PT
Figure 10: NAT-PT in SEINIT global architecture
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 21 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
2.2 DNSsec
2.2.1 Functional description
DNS Security (DNSSEC) technology is a set of extensions to the Domain Name System (DNS) protocol that
provide data integrity and data origin authentication to security aware resolvers and applications, mainly
through the use of public-key cryptography. In DNSSEC, each node in the DNS tree is associated with a
public key. Each message from DNS servers is signed under the corresponding private key associated with
the public key of the domain. It is assumed that one or more authenticated DNS root public keys are publicly
known. These keys are used to generate a digital signature that binds the identity information of each
top-level domain to the corresponding public key. The top-level domains sign the keys of their subdomains
and so on in a process where each parent signs the public keys of all its children in the DNS tree.
DNSSEC defines the following basic Resource Records (RRs):
• RRSIG. It is used to store digital signatures associated to a Resource Record Set (RRset).
• DNSKEY. It is used to store a public key. The key is associated with a DNS zone.
• NSEC. To be able to provide data origin authentication of a non-existent name or the nonexistence of a certain resource record type for a DNS name.
• DS. It refers to a DNSKEY RR and is used in the DNS DNSKEY authentication process. By
authenticating the DS record, a resolver can authenticate the DNSKEY RR to which the DS
record points.
Additionally, some other RRs are being defined to store cryptographic information:
• CERT. It is used to store certificates in the DNS. The types of certificates currently defined are
X.509, SPKI and PGP certificates. As the CERT record can contain a certificate, it is possible to
use DNS for storage of the certificates and CRLs issued by a public key infrastructure.
Regarding transaction security mechanisms, two different ones are defined:
• Transaction signatures (TSIGs) based on symmetric cryptography. TSIGs are created using
symmetric encryption methods, meaning that the parties involved in the communication need to
have a shared secret.
• Public-key signatures, SIG(0). It is similar to TSIG but employs public-key signatures. SIG(0)
may not be practical to use on a large scale but it is useful in case integrity protection and
authentication of the message as a whole are desired.
2.2.2 State of art
UMU has deployed and tested DNSSEC in two ways. On the one hand, UMU has deployed DNSSEC
scenarios establishing trust relationship between hierarchical secured DNS servers, using the TSIG
mechanism for exchanging data securely between zones, and using the DNSSEC-defined RRs in queries and
updates.
On the other hand, UMU has integrated DNSSEC with the UMU-PKIv6 solution, as shown in Figure 11,
allowing DNSSEC to act as a public key certificate repository using the new resource records (e.g. CERT)
defined by the protocol.
UMU-PKIv6
cert.request
DNSSec
Module
TSIG(cert/crl. publish)
get cert./crl
End User
get cert./crl
DNS/DNSSec
Server
Figure 11: Integration of DNSSEC and the UMU-PKIv6
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 22 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
The DNSSEC reference implementation is the ISC Bind Nameserver (Version 9.x). Bind9 supports DNSSEC
to sign zones and TSIG to sign DNS requests, while SIG(0) is partially supported to authenticate DNS
requests and access control (e.g. SIG(0) to sign multiple-message TCP streams is not supported).
Other tools can be found regarding DNSSEC applications (http://www.dnssec.net/software.php), like
dnsjava, DNSSec Resolver, DNSSec Toolkit¸ etc.
2.2.3 Purpose in SEINIT
DNSSEC is a new component that could be included in a secure domain. It could be used in SEINIT to
protect DNS transactions between the components of the domain and the zone transfer operations with other
secure domains. It could be also considered as a digital certificate repository (associated with a PKI, as the
UMU-PKIv6) to offer an easy way to locate other peer’s certificates before establishing secure
communications with them.
2.2.4 Adaptation and use
DNSSEC could be deployed in the SEINIT base scenario, allowing the interaction with other DNSSEC
servers and the publication and retrieval of digital certificates and CRLs. DNS servers and resolvers need to
be updated to support the new DNSSEC-defined RRs and to process the new format of DNS requests and
responses (which include digital signatures that must be validated by resolvers, for example).
2.2.5 Interaction with other components
Secure DNS transactions involve interactions between DNS servers and local resolvers; on the other hand,
using DNSSEC like a key repository involves applications using public/private key cryptography. For them,
it is an easy way to recover other entity’s keys; for example, DNSSEC key repository is used by
opportunistic encryption applications like a fast and scalable way to access other’s peers public key
certificates.
To store and manage keys in a DNS repository interaction with a PKI is needed; the UMU-PKIv6, presented
below (section 2.3.1.2), allows managing in a secure way (using secure channels) the interaction with
DNSSEC servers.
2.3 IPv6 routing security
2.3.1 Functional description
IPv6 routing is implemented using a distributed system composed of many routers, grouped into
administrative domains called Autonomous Systems (ASes). Routing information is exchanged between
ASes using Border Gateway Protocol (BGP) UPDATE messages.
OSPF is a link state protocol designed to be used in a single AS. Each router is responsible for meeting their
neighbors and learning their names. Every router constructs a packet known as Link State Advertisement
(LSA), which contains a list of the names of their neighbors and the link cost to the neighbors. These LSAs
are flooded to all other routers periodically, or whenever any new information is available. Each router uses
these LSAs to form the complete view of topology, and computes the route to each destination.
Those two routing protocols are not secured.
The BGP protocol has some security weaknesses, which can cause deception, disruption and disclosure of
routing message traffic. And OSPF routing protocol offers no mechanisms to confirm the source authenticity
and distributed routing information integrity. But some measures exist to minimize or eliminate those threats.
The digital signature is a security mechanism to protect the authenticity and integrity of the OSPF routing
information distribution.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 23 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
OSPF use several LSAs, which contain the addresses of the interface, of the network of the router, etc. Each
router discovers its neighbours via a Hello protocol and exchanges its routing information database. An LSA
is send through the network when the information carried changed.
The basic idea of a secure OSPF design is to add digital signature to OSPF LSA data, and to use a
neighbour-to-neighbour authentication algorithm, like MD5, to protect all protocol exchanges.
The sender of the information will sign it and this signature will travel via the OSPF flooding. This will
provide end-to-end integrity and authentication for LSA data. If a fake router distributes wrong routing
information, the signature will allow finding it.
When a router receives a LSA routing information, the signature should be verified using the current public
key of the sender. If there is no key stored for this sender, or if the signature verification fails, the LSA must
be discarded. If the signature verification is ok, the signed LAS will be stored for use in the routing
calculations. The computed routes will be put into the OSPF routing table.
Each router has a couple of keys: a private and a public key. The distribution of the public key and the
binding between that key and the router is very important to the system security. If key management and
distribution mechanisms independent of the routing protocol exist, they could be used to provide couple of
keys to external routers. The private key must be kept secret by one router and the public key must be
distributed to all the routers that will receive link state information from the signer. Creating a new LSA, the
Public Key LSA (PKLSA), and distributing it via the standard OSPF flooding procedure accomplish the
distribution. Flooding will ensure that a router public key is sent everywhere that the router’s signed LSAs
are sent. The design assumes that there is a trusted entity, which signs all routers certificate. Each router has
also the trusted entity public key to verify others routers certificates. A router which receive a PKLSA,
verifies the certificates using the trusted entity public key, and after verify the whole LSA using the router
public key contained in the certificate.
The BGP protocol has some security weaknesses too. For example, one of its vulnerabilities allows an
intruder to fabricate, modify or delete routing information. This can cause a denial of network services, a
disclosure of network traffic or an unavailability of the network resources. This attack exploits the lack of
access control, authentication, and integrity of BGP message contents.
Another vulnerability is that it is relatively easy for an intruder to gain access to routing traffic, including the
appropriate next hop to reach a destination and the path taken by traffic to different destinations. This attacks
exploits the lack of confidentiality of peer links, and the level of trust placed in BGP speakers.
A solution to secure BGP is to encrypt all BGP messages between peers using session keys exchanged at the
BGP link establishment time. This encryption provides integrity and authenticity of all path attributes and
confidentiality of all routing exchanges. To protect against replayed or delete messages, a message sequence
number is required. Same method to avoid the update messages replaying, with an update sequence number.
A solution must also allowed to digitally sign all unchanging update fields whose values are fixed on
creation by the BGP speaker originating or most recently aggregating the route, to provide integrity and
authenticity.
The peer-to-peer encryption and peer-to-peer sequence number are providing corruption detection,
sequencing, acknowledgement and retransmission mechanisms that are redundant to those provided by TCP.
They are required, due to the insecurity of TCP mechanism.
2.3.2 State of art
•
All the router of the THC test-bed platform are compliant with BGP.
2.3.3 Purpose in SEINIT
In SEINIT, those two principal routing protocols will be used and must be secured. We want to have a
visibility over the security deployed all along the transaction. Each routers will send back informations on
the security mecanism it apply to respect the negociated security policy. It mean that we must protect the
network against intruders and faulty routers participation.
2.3.4 Adaptation and use
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 24 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Before a transaction the sender and the receiver must find a common security policy, called “negociated
security policy”. The security policies requirements should be integrated in the OSPF LSA to become a
SEINIT compliant routing information.
2.3.5 Interaction with other components
In the case of OSPF, the digital signature implementation will required the use of a PKI. The secured BGP
allows a more decentralized and incremental security.
2.4 IPsec enhancements
2.4.1 Functional description
IPsec is designed to provide interoperable, high quality cryptographically-based security for IPv4 and IPv6.
A set of security services offered which includes connectionless integrity, access control, protection against
replays (a form of partial sequence integrity), data origin authentication, confidentiality (encryption), and
limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP
and/or upper layer protocols and applications.
The security services as described above are met through the use of two traffic security protocols and
through the use of cryptographic key management procedures and protocols. The used security protocols are
the Authentication Header (AH) and the Encapsulating Security Payload (ESP). A possible cryptographic
key management procedure and protocol is the Internet Security Association and Key Management Protocol
(ISAKMP). The IPsec standards define a framework and protocols for usage, the context and ways in which
they are employed can be determined by the security and system requirements of users, applications, and/or
sites/organizations. The used mechanisms are designed to be algorithm-independent, i.e. this modularity
permits the selection of different sets of algorithms without affecting other parts of the protocols.
IPsec can operate two modes, host mode and security gateway mode. In host mode, it protects the
communication between two hosts or between a host and a security gateway where the host exchanges data
with systems behind the security gateway (e.g. mobile systems accessing company network via company
IPsec Gateway). In security gateway mode, it can protect the private communication between several private
networks, building a VPN, over public networks.
For negotiating Security Associations, exchanging and managing cryptographic keys, IPsec utilizes the
ISAKMP protocol. ISAKMP offers two "phases" of negotiation. In the first phase, two entities (e.g.
ISAKMP servers) agree on how to protect further negotiation traffic between them, establishing an ISAKMP
SA. This ISAKMP SA is then used to protect the negotiations for the Protocol SA being requested. Two
entities (e.g. ISAKMP servers) can negotiate (and have active) multiple ISAKMP SAs. The second phase of
negotiation is used to establish security associations for other security protocols. This second phase can be
used to establish many security associations. The security associations established by ISAKMP during this
phase can be used by a security protocol to protect many message/data exchanges. For system authentication,
several mechanisms can be used, starting from pre-shared secrets, to RSA public / private keys and X.509
certificates. Furthermore, enhancements exist which can also provide user authentication during the
ISAKMP negotiation.
2.4.2 State of art
•
IABG has already utilized IPsec in two ways. First, it was deployed in many scenarios where static
VPNs have been built to secure network to network communication over public infrastructure (utilizing
the security gateway mode). The VPN gateways used an IPv6 enhanced version of the Linux based IPsec
implementation FreeS/WAN and authenticated each other by pre-shared secrets, RSA public / private
keys, or X.509 certificates with a static, offline PKI solution.
The second deployment of IPsec was its usage in many scenarios where mobile systems (so called Road
Warriors) used IPsec to connect themselves to their security gateway (i.e. organization IPsec gateway) in
order to securely communicate with their private network (e.g. organization network) and use the
provided services of that network (e.g. Mail, FTP).
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 25 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
•
THC has deployed the IPSec protocol in its core test-bed platform. First, IPSec has been deployed
between two hosts' stations to test the protocol. Then, IPSec has been deployed in the edge router of the
THC platform to be able to create a VPN.
The Security Associations (SA) IPSec are dynamically managed by the IKE protocol. An internal PKI is
available to manage and deliver the certificates necessary for the entities authentication implicated in the
IKE exchanges.
THC global network security architecture (IPSec, IKE, PKI) enables to create VPN in their core network
and to transport data in a secure manner. The creation of the VPN is automated by using a policy
manager. Just by entering the policies in GUI software, the administrator is able to configure the core
network and to create the associated tunnel and security association.
The first tests on security have been done between two Linux PCs by using the Freeswan stack. Further
tests have been realised between 6WIND gate and Linux edge, showing the interoperability of the
different security stacks. Security APIs allows abstracting the notion of vendor and sending common
rules to different vendor's equipment. A minor adaptation level is needed to enforce the rules in the right
manner (Freeswan orders under Linux...) in each specific equipment.
Additional work has been realised on dynamic security; to provide persistent security services. The
secure tunnel is automatically rebuilt whatever the network constraints, even on link failure: verification
of the tunnel, detection of the failure, management entity alert, automatic response by deleting the past
tunnel and a new one using a new route.
•
Alcatel has implemented IPSec (RFC 2401), AH (RFC 2402) and ESP (RFC 2406) based on KAME
implementation in its Common IP Routing Stack. Both Transport and Tunnel mode are supported. The
key management is manual keying. Implementation has been intensively tested using TAHI IPv6
Conformance Test Suite: IPsec AH and ESP from IPv6 (Host and Router) enhanced with an exhaustive
set of home made test cases.
2.4.3 Purpose in SEINIT
IPsec is a well known component which could be included in usage scenarios of SEINIT which could require
strong authentication and strong security on the network layer for e.g. various transport protocols and
applications. It could be also considered as possible solution to provide secure communication of mobile
users to their company or private network, or to securely connect several private security domains over
public infrastructure.
2.4.4 Adaptation and use
IPsec could be deployed in the SEINIT base scenario, allowing the interaction with other IPsec instances to
generate ad hoc Security Associations by using either already distributed authentication resources or public
available authentication resources. The available IPsec implementations of IABG could be updated to
support dynamic security policy configuration and to make their current status (e.g. established Security
Association, currently trusted systems, used encryption algorithms, used authentication mechanisms /
algorithms) easier accessible by users or administrators. Furthermore, the available IPv6 enhanced
implementation of IPsec, which is currently based on Linux kernel 2.4.x and consists of a kernel
implementation of IPsec and a user space daemon for ISAKMP negotiations, could be examined for mapping
it on the new Linux kernel 2.6.x which already provides a basic kernel implementation of IPsec.
The following subsections describe possible adaptation and usage with respect to the interaction with other
component, support for mobile users, improved key management and robustness:
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 26 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Support for mobile users
For mobile users, it could be a possibility to utilize IPsec to secure their communication to their trusted home
network. This could mean that the used IPsec implementation could be enhanced in such a way that it detects
the movement of the mobile system to a new network and establishes a secure connection to the well known
IPsec gateway protecting the home network. It could also mean that SEINIT has a look at the public Open
Source implementations available at that time and which combine IPsec together with Mobile IPv6.
Improved key management
As the current IPsec standard, especially the ISAKMP protocol, is quite complex, effort is made by the
responsible standardization body and group to define a successor, which provides comparable strong
security, while being less complex for implementation and management. It could be interesting for SEINIT
to examine the new proposed protocols and possibly public available Open Source implementations with
respect to their effects on the SEINIT framework and architecture.
Robustness
When deploying IPsec services in a heterogeneous environment (as the SEINIT environment will by its
nature) robust interoperability between different implementations is a critical key feature. In SEINIT it could
be therefore interesting to investigate possible interoperability issues between the used different IPsec
implementations. Furthermore, as there is always the chance that the negotiation between two different IPsec
instances fails (i.e. due to lacking authentication material, mismatching security policies), with respect to
robustness of secure communication, it would be interesting to investigate the fail behavior of different IPsec
implementations and the resulting communication parameters (e.g. communication not permitted, clear text
communication, communication with lower security requirements as initially specified).
2.4.5 Interaction with other components
Utilization of IPsec involves the interaction of possibly different IPsec implementations for negotiating
Security Associations and to actually process the exchanged data. Furthermore, given the SEINIT approach
of dynamically establishing a certain level of trust to services and components in new visited environments,
the dynamic distribution / exchange of authentication material could be a new interaction of IPsec with other
components (e.g. DNSSec servers).
2.5 Mobility in secure architectures (Return Routeability)
2.5.1 Functional description
Within Mobile IPv6 the communication partners (or correspondent nodes) of a mobile node will be informed
about its current location by receiving mapping information from the mobile node, which map the IPv6
address the mobile node is usually using at its home network to the IPv6 address the mobile node is currently
using on its visited network. Knowing this mapping the correspondent nodes can exchange information with
the mobile node on the direct way, avoiding a detour by sending the information first to the mobile node’s
home network, from where it will be forwarded to the mobile node’s current location by the Home Agent.
This mapping information is transferred from the mobile node to the correspondent node within Binding
Updates, messages carried in the IPv6 Mobility Header.
It is obvious that these Binding Updates represent an ideal target for attackers. On behalf of a mobile node an
attacker could send a Binding Update to the correspondent node, using the mobile node’s home address, and
map it onto the current IPv6 address of the attacker. In this way the whole traffic from the correspondent
node to the mobile node would be re-directed to the attacker. Therefore it is necessary to provide an
appropriate authentication mechanism for the exchanged Binding Updates. The Mobile IPv6 protocols
foresees for this purpose the return routability mechanism depicted in Figure 12.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 27 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
visited
network
home
network
Internet
Mobile Node
Home Agent
Correspondent Node
Home Test Init (HoT cookie)
Care-of Test Init (CoT cookie)
Home Test (HoT cookie, home keygen token, home nonce index)
Care-of Test (CoT cookie, care-of keygen token, care-of nonce index)
Figure 12: Overview of the return routability process
- Care-of Test Init Message: A mobile node uses the Care-of Test Init (CoTI) message to initiate the
return routability procedure and request a care-of keygen token from a correspondent node.
- Home Test Init Message: A mobile node uses the Home Test Init (HoTI) message to initiate the
return routability procedure and request a home keygen token from a correspondent node.
- Home Test Message: The Home Test (HoT) message is a response to the Home Test Init message, and
is sent from the correspondent node to the mobile node.
- Care-of Test Message: The Care-of Test (CoT) message is a response to the Care-of Test Init
message, and is sent from the correspondent node to the mobile node.
During this return routability mechanism the mobile node and the correspondent node exchange 4 messages,
one message from the mobile node to the correspondent node sent via the Home Agent (Home Test Init) and
the respective reply belonging to it (Home Test), and another message sent direct from the mobile node to
the correspondent node (Care-of Test Init) and the respective reply belonging to it (Care-of Test). Within the
replies from the correspondent node, the Home Test and Care-of Test messages, two tokens, which are
generated by the correspondent node, are transmitted to the mobile node. The mobile node uses both tokens
and derives a key from them, which is in turn use for generating a Message Authentication Code for the
following Binding Updates.
If an attacker still wants to send Binding Updates on behalf of a mobile node, it would need to know both
tokens in order to be able to reproduce the key used for signing the Binding Updates. As both replies from
the correspondent node to the mobile node take different paths (via the home agent and directly),
consequently both tokens are sent on different paths, that is the attacker would need to be able to eavesdrop
both paths. This could be for example the case if an attacker is very close to either the mobile node, or the
correspondent node. The first case could be prevented by encrypting all information exchanged between
mobile node and home agent using IPsec ESP. This would leave for an attacker close to the mobile node
only the possibility to eavesdrop communication done directly with the correspondent node, which is
insufficient for intercepting both tokens. The latter case, that is an attacker close to the correspondent node,
cannot be prevented by the return routability mechanism so far. If such an attacker is able to eavesdrop
communication exchanged between the correspondent node and the mobile node directly, as well as via the
home agent, it will obtain both tokens, can re-produce the appropriate key, and use this for signing faked
Binding Updates.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 28 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
2.5.2 State of art
- The basic functionality of return routability has been part of the Mobile IPv6 draft version 17. The current
version 24 of the Mobile IPv6 draft specifies already a return routability mechanism, which is mature enough
for implementations.
- A first implementation for Linux is available from the Helsinki University of Technology.
- Alcatel has implemented draft-ietf-mobileip-ipv6-21.txt and draft-ietf-mobileip-mipv6-ha-ipsec-06.txt to
add security in mobility. Return Routability has been implemented and protection of HOT/HOTI with IPSEC
tunnel mode is supported. Implementation has been intensively tested using TAHI IPv6 Conformance Test
Suite enhanced with an exhaustive set of home made test cases.
2.5.3 Purpose in SEINIT
Return routability is used to secure the exchange of Binding Updates between mobile nodes and
correspondent nodes. This exchange is required in order to allow route optimization for mobile nodes, that is
to allow the direct communication between mobile node and any correspondent node without involving the
home agent.
One major aspect dealt within SEINIT is exactly security for mobile users in wireless network. In this
context Mobile IPv6 could be used for supporting the roaming of mobile nodes between different IPv6
subnetworks, e.g. between different segments of a WLAN hot spot. In order to secure this roaming, the
return routability mechanism can be used.
2.5.4 Adaptation and use
Return routability will be used in all SEINIT scenarios, in which Mobile IPv6 is selected to support the
mobility of mobile nodes. This could be for example the roaming between different IP subnets of a single or
of different WLAN hot spots.
2.5.5 Interaction with other components
The return routability mechanism is an integral part of the Mobile IPv6 protocol. Inside this Mobile IPv6
protocol return routability will mainly cause an interaction between mobile node and correspondent node.
Additionally the exchange of the Home Test Init and Home Test messages will involve the home agent,
however, the only task required of the home agent in this context is the interception of packets destined for a
mobile node’s address on the home link during the absence of the mobile node (proxy functionality) and the
forwarding of these intercepted packets to the current location of the mobile node.
Additionally the return routability mechanism should be integrated efficiently with the IPv6 Neighbor
Discovery mechanism. Before triggering the return routability mechanism the mobile node has to configure a
new address on the visited network and perform Duplicate Address Detection for it. First after completion of
the Neighbour Discovery process the return routability mechanism should be started. However, this
interaction is nowhere specified in detail, and therefore up to the implementations.
2.6 Access Control managed with CGA
2.6.1 Functional description
Cryptographically Generated Addresses (CGA) is a method for binding a public key to an IPv6 address. An
IPv6 address is divided in two parts, the leftmost 64 bits of a 128-bit address form the subnet prefix and the
rightmost 64 bits of the address form the interface identifier (IID). This IDD is generated by computing a
cryptographic one-way hash function from a public key and auxiliary parameters. This binding can be
verified by another part re-computing the hash value and comparing the hash with the interface identifier, so
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 29 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
the node sends the CGA parameters to the other part to make the verification. Messages sent from an CGA
address can be signed using the private key.
CGA themselves are not certified, an attacker can create a new CGA from any subnet prefix and its own
public key, but that the attacker cannot to do is to take a previously created CGA by someone else and sends
signed messages that appear to come from the owner of that address. That's why certificates are going to be
used to provide identification to hosts. The certificate’s public key will be used as key to generate CGA and
obviously the associated private key will be used to sign messages.
CGA is used with SEND (Securized Neighbour Discovery). SEND has introduced several options to
Neighbour Discovery Protocol (NDP) to protect NDP messages. These options are Certificate Chains (to
avoid “rogue” routers on an unsecured link), CGA (to verify CGA address by other node), Signature (to sign
messages with CGA public key), Timestamp and Nonce (to protect messages against replay attacks).
2.6.2 State of art
Nowadays, there is not an implementation of CGA and SEND. But it is should be considered to use it
because it provides solutions to actual security problems which exist in NDP. This problem is the lack of a
mechanism to secure signaling and SEND fixes it.
2.6.3 Purpose in SEINIT
SEND is used to provide a secure mechanism to discover each other's presence, to determine each other's
link-layer addresses, to find routers, and to maintain reachable information about the paths to active
neighbours. The purpose of CGAs is to prevent stealing and spoofing of existing IPv6 addresses. In addition,
“Certificates chains” helps us to prevent that a host can make a function which is not allowed, for example:
An answer from a hostile host to a “Router Discovery” message must be discard.
2.6.4 Adaptation and use
Certificates are used to generate CGA address, so SEND has to be modified to recover certificates from a
DNSsec by mean CGA address or from a LDAP repository and so it can check the host identity.
2.6.5 Interaction with other components
To verify the identity of a host with CGA, the certificate associated has to be recovered from a repository. A
DNSsec can be used for that where the certificate will be associated to the host by a CGA(IPv6). At first, the
certificates are stored in a PKI, so PKI certificates have to be copied to DNSsec and to be associated with
CGA address. In a mobile environment, the IPv6 address, in this case, CGA address, is going to be different
when a host changes the access point to the link, so in DNSsec the certificate has to be associated with the
new CGA address.
No additional security infrastructure, such as a public key infrastructure (PKI), certification authorities, or
other trusted servers, is needed.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 30 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
3 Supplementary Access Control functionality
3.1 Access Control Infrastructure
3.1.1 AAA
3.1.1.1 Functional description
Communications and networks have undergone a fast growth in last years. Due to the increase in the number
of users and the request for new services, Telecommunication Operators need mechanisms, protocols and
infrastructures that allow them to manage and control users. A framework providing a suitable support for
this is known as AAA (Authentication, Authorization and Accounting) framework. Service providers (SPs)
need a way to determine if a user that tries to use their resources is allowed to do it. It is carried out, firstly,
by executing an authentication process that allows SP to know user identity and if this one has a business
relationship with him; then an authorization process is fulfilled to determine whether a requesting entity will
be allowed to access to a resource and how. Furthermore, a process is needed to collect resource usage
information; it is known as accounting.
These three concepts include different infrastructures and protocols (AAA protocols) in order to support
Internet services with AAA requirements. However, this is not a novel idea due to the vast majority of
current SPs have deployed these infrastructures for years. The problem is these current infrastructures are
based on protocols as RADIUS and TACACS+, and they can be considered as antiquated as they were
designed to support a specific kind of user (dial-up PPP users) and access technology. But these ideas are
also important when we talk about mobility and roaming scenarios, because it is needed to be aware about
which user/users can connect to a foreign network and what things they can do inside these networks. Thus,
another kind of AAA protocol is needed to support new requirements raised by mobility: IETF’s and 3GPP
consortium’s solution has been the Diameter protocol.
In its base specification, Diameter protocol defines several entities that could be deployed in a AAA
infrastructure, namely:
• Relay agents, in charge of forwarding requests and responses to the AAA server that manages
information about a particular user.
• Proxy agents work similarly as relay agents; however these entities takes decisions about AAA
information routing based on policies relating to resource usage and provisioning, and the
destination domain.
• Redirect agents send information after a previous request about how to reach a AAA server
directly in a requested domain; these agents are deployed in order to reduce the configuration
information to reach different domains that would otherwise be necessary on all servers owned
by members of a roaming consortium.
• Translator agents that are in charge of translating requests/answers from RADIUS protocol into
Diameter requests/answers.
• Brokers they are intermediate elements shared between two or more administrative domains.
From a functional point of view, they could be proxy agents, simple relay agents or redirect
agents providing service to several domains.
• Authentication/Authorization server (AA server). It is the entity containing information about
end-users and controlling authentication and authorization functions.
• Accounting server. This entity registers and collects information about end-user’s service usage.
3.1.1.2 State of art
A Diameter base protocol implementation is needed in order to develop scenarios and AAA infrastructures
based on the Diameter protocol. Thus, UMU is jointly collaborating with Toshiba Research in the
development of new functionalities in a Diameter implementation (Open Diameter). It is mainly developed
by Toshiba Research team but we are helping by adding new features and improving the protocol. Open
Diameter implementation has several interesting features:
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 31 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
• It defines C++ API, which is well structured and extensible enough to be used for writing any
Diameter application.
• It is carefully designed to gain a great level of performance in multithreading environments and
is totally thread-safe.
• It is written by using modern C++ libraries such as ACE, which makes the source code portable
to various types of operating systems.
These three design philosophies archive the goals of extensibility, performance and portability,
without sacrificing any of them.
• It integrates an EAP state machine to develop new EAP methods.
• Diameter EAP Application has been developed
• In the same package, an implementation of PANA protocol has been included.
• Currently, UMU is developing new functionalities based on this implementation:
1.RADIUS – Diameter translator implementation: to allow to a smooth transition from old
RADIUS-based infrastructures to new Diameter-based AAA ones.
2.EAP-TLS method integrated with Open Diameter EAP state machine and with Diameter EAP
Application: it is useful to allow authentication based on X509 certificates.
3.1.1.3 Purpose in SEINIT
The main purposes of the Diameter in the SEINIT framework are both to manage and control users, and to
carry out processes related with authentication, authorization and accounting in intra- and inter-domain
scenarios.
3.1.1.4 Adaptation and use
Depending on requirements inside project, new Diameter applications could be needed and these
implementations and modules should be adapted to the Open Diameter implementation. For example,
currently EAP module has been developed, and MIPv4 application is on-going but more applications can be
added (i.e. MIPv6 application, NASREQ application etc…)
3.1.1.5 Interaction with other components
Diameter-based AAA infrastructures need to interact with other different protocols and infrastructures,
namely:
• PKI: to allow to certificate Diameter entities in infrastructure.
• EAP protocol: to allow to process authentication information.
• PANA protocol: to recover EAP packets transported by this protocol and to encapsulate them in
Diameter EAP application to carry out authentication/authorization process.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 32 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
3.1.2 PKI
3.1.2.1 Functional description
Public Key Infrastructures are defined to provide Public Key Certificate (PKC) management to the group of
security protocols designed to protect Internet. These protocols, for instance, IPsec, SSL, TLS or S/MIME,
use public key cryptography to provide services such as confidentiality, data integrity, data origin
authentication and non-repudiation. Users of public key-based systems need to trust in a PKC. A PKC is a
data structure, which binds a public key to the user identity and other information like certificate’s validity
period, serial number, issuer entity or extensions. This binding is achieved by having a trusted third party,
Certification Authority (CA), which verifies the subject identity and digitally sign each digital certificate.
A PKI includes software, policies, hardware, etc, allowing the creation, management, storage, distribution
and revocation of public key certificates. The main components of a generic PKI are: Certification
Authorities (CAs), which issue, validate, renew and revoke PKCs, Registration Authorities (RAs) to
authenticate off-line users and add certificate’s properties, PKI’s end users or systems, who can encrypt, sign
and validate digital documents from a known public key of a trusted CA, and public repositories, to make
available certificates and certificate revocation lists (CRLs).
3.1.2.2 State of art
The PKI designed by University of Murcia, named UMU-PKIv6, defines a complete group of certification
services for any secure domain that need to provide its clients of security mechanisms in their
communications. By means of their services, users will be able to carry out several operations: to request a
certificate, renew or revoke it, to look for another user certificate, etc. Moreover, it allows users to use smart
cards (which can be distributed by the own organization) to store cryptographic information, so that it
facilitates their mobility.
Main features:
• Users can issue, renew and revoke certificates.
• LDAPv6 directory supported to store users and CAs certificates and CRLs.
• Final users can carry out certification operations from their own navigator or through RAs.
• Users can storage cryptographic information (private key, certificate and CAs certificate) in
their smart cards
• Policy definition will establish the opportune restrictions inside an organization.
• PKIv6 has been developed completely in Java.
• It is based on standards specified by the IETF inside the PKIX work group.
• SCEP (Simple Certificate Enrolment Protocol) protocol supported for VPN Clients.
•
•
•
•
Certificate life-cycle mechanisms as CMC supported.
DNSSEC support, publishing of certificates, CRLs, etc. as presented above (section 2.1.2)
Cross-certification is allowed in two ways, peer-to-peer and hierarchical cross-certification.
It offers services of Time Stamping and certificate’s status on-line (OCSP).
• It supports advanced research PKI services, like self-revocation and re-issue of certificates.
• Communications between components can be based on IPv4 or IPv6.
The UMU-PKIv6’s main components are showed in the next figure:
• Certification Authorities (CAs) to issue, renew and revoke PKCs.
• Registration Authorities (RAs) authenticate off-line users and add certificate’s properties.
• PKI clients can encrypt and sign digital documents or establish secure connections.
• Request Server like an intermediate element between end users and RAs and the CA (only
outbound communcications).
• Public repositories to make available certificates and certificate revocation lists (CRLs). It can
be a DNSSEC server.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 33 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Cert/CRL Repository
SD
End User
Router
CA
RA
Requests Server
Figure 13: UMU-PKIv6 components
3.1.2.3 Purpose in SEINIT
Interaction with other components
The use of a Public Key Infrastructure is a key point in a secure domain based on public/private keys.
Cryptography material is the base for all the security mechanisms used in an environment like the SEINIT
project, so it is necessary a well-known, widely used and easily adaptable solution, as the PKI.
PKI will provide cryptography material for every entity inside the secure domain and it should also help
entities to manage the life cycle of these keys.
3.1.2.4 Adaptation and use
If PKI services should be available for every component in a secure domain, or components of foreign
domains, PKI has to be adapted to the characteristics of every different component; this adaptation includes
the use of a wide range of protocols and APIs to cover all the possible PKI’s clients.
With these access methods to the PKI, every entity can reach the PKI to manage its cryptography
information to establish secure channels with other components inside the same or different trusted domain.
These access points have to be based on specific standards, like the use of CMC or CMP protocols, offer
easy APIs with common protocols, like HTTP, FTP, SCP, SCEP, etc and APIs for system requiring a special
treatment.
3.1.2.5 Interaction with other components
The public and private keys issued by a PKI are used by the majority of the SEINIT components.
IPsec/SSL/TLS protocols usually need asymmetric keys to establish trusted secure channels. DNSSEC can
use public/private keys to secure DNS transactions and moreover, it can be used to store public key
certificates used, for example, by opportunistic encryption applications. AAA and EAP modules should be
used with asymmetric keys for authentication and authorization decisions, and CGA address can be
composed using public/private key pair.
Due to the high presence of the PKI in the secure domain, most of the SEINIT components will have to take
a public key certificate and the associated private key.
3.1.3 Privilege Management Infrastructure
3.1.3.1 Functional description
Privilege Management Infrastructures (PMIs) are defined to provide privilege information to users, and issue
and manage it by using X.509 Attribute Certificates. An Attribute Certificate (AC) may store privilege
information such as roles, group membership, etc. Usually, a PMI may be used as a role based access control
infrastructure through the user’s privilege management, data origin authentication or non-repudiation. A PMI
is to authorisation what a PKI is to authentication.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 34 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
The ACs need be bound to one identity which provides a strong authentication process during the
establishment of the holder’s identity. For this reason, an AC is bound to one PKC to provide this
authentication. The main components of a generic PMI are: Attribute Authorities (AAs), which issue and
revoke ACs, Access Points (APs) to authenticate off-line request user privileges, Clients to request an action
for which authorisation checks are to be made and Repositories (such as LDAP) to store and make available
Attribute Certificates.
3.1.3.2 State of art
The University of Murcia has developed a prototype of Privilege Management Infrastructure, UMU-PMIv6,
using Attribute Certificates. It defines a group of services for the clients that need to benefit from
authorization mechanisms through privilege information management.
By means of their services, a client can obtain the basic operations: to request an AC, revoke it, only retrieve
his ACs, etc.
Main features:
• Users can issue and revoke attribute certificates.
• LDAPv6 directory supported to store users and AAs attribute certificates and ACRLs.
• Policy definition will establish the opportune restrictions inside an organization.
• PMIv6 has been developed completely in Java.
• It is based on standards specified by the IETF inside the PKIX work group.
• It offers services of AC validation such as Simple Certificate Validation Protocol (SCVP).
• Communications between components can be based on either IPv6 or IPv4.
The UMU-PMIv6’s main components are depicted in the Figure 14. Note that the conceptual design is based
on the UMU-PKIv6 as both infrastructures have some similarities.
• Attribute Authorities (AAs) issue and revoke ACs.
• Access Points (APs) authenticate off-line users and add certificate’s properties.
• PKI clients can encrypt and sign digital documents or establish secure connections.
• Request Server like an intermediate element between end users and APs and the AA.
• Public repositories to make available ACs and ACRLs.
Figure 14: UMU-PMIv6 components
3.1.3.3 Purpose in SEINIT
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 35 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
A PMI is an interesting component within a security environment where intra-domain access (even
inter-domain access) can be related to several constraints or privileges associated to these users.
UMU-PMIv6 can issue and manage the life cycle of such privileges.
3.1.3.4 Adaptation and use
Currently, UMU-PMIv6 is only a prototype that needs some additional work. The IETF PKIX Working
Group is working in this area to provide the required standards for certificate status checking, retrieval, etc.
As the use of attribute certificates could benefit services and applications developed in the SEINIT
framework, some work could be required in them for being able to process and manage this kind of
certificates. It could be also the case of the software used by end users.
3.1.3.5 Interaction with other components
Mainly, the PMI will need to interact with the PKI to provide the necessary authentication process during the
establishment of the holder’s identity. Users, services and applications making use of attribute certificates
also need to interact with the PMI to request, validate and/or revoke an AC.
3.1.4 Security Assertion Markup Language(SAML)
3.1.4.1 Functional description
SAML is an OASIS standard designed to transport security information. It is an XML-based technology for
exchanging information about the authentication status of an user/terminal, the attributes of an user/terminal
and may include authorization information, e.g. to which resources an user/terminal has access-rights. This
standardized information is formed in XML and is called SAML assertion. SAML offers independence from
the used authentication mechanism: different authentication server in different domains can authenticate the
user/terminal using any authentication mechanism. After successful authentication, a standardized assertion
is generated. This assertion is used for exchanging security information in a standardized way. The entities
requiring authentication only need to support SAML and not all authentication mechanisms.
SAML supports digital signatures via the mechanism of XML Signatures. It supports encryption via XML
Encryption objects.
SAML is complemented with XACML (eXtended Access Control Markup Language) also an OASIS
standard to provide a language for standardized description of policies and the requests/responses for
authorization decisions. SAML is targeted at these use cases amongst others: Single-Sign On; B2B
transactions; Authorization (in a service environment).
3.1.4.2 State of art
UMU is deploying a SAML authority used to issue authentication and authorization credentials. This
authority is based on the SAML Open Source implementation and will offer a web interface to entities
requesting SAML credentials.
SAML Authority implementation will interact with public key infrastructures (UMU-PKIv6) and with AAA
server to be used in SSO scenarios and network access control, see below.
3.1.4.3 Purpose in SEINIT
SAML is a new standard for authentication and authorization and these are requirements that the SEINIT
secure domain should take into account. SAML can be used to offer security based on Identity, Roles,
Attributes, etc.
3.1.4.4 Adaptation and use
The use of SAML implies some components should be adapted to support assertions, components like AAA
server, application services or end user devices could require to understand the SAML language. Depending
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 36 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
of the king of authentication/authorization services defined in SENIT, components should be or not be
adapted.
3.1.4.5 Interaction with other components
An SAML authority could interact with a PKI to provide cryptographic material. It will be used by end
user’s web browsers, application services and AAA server. SAML authorization can also be use to get
access control based on 802.1x using EAP authentication like shows the above figure.
3.1.5 Protocol for Carrying Authentication for Network Access (PANA)
3.1.5.1 Functional description
PANA is a link-layer agnostic protocol to transport EAP protocol to enable network access authentication
between clients and access networks. Due to PANA can transport any EAP method, different authentication
methods are supported. PANA can work on any link that can carry IP.
PANA defines several entities:
• PANA Client (PaC): The client side of the protocol that resides in the host device, which is
responsible for providing the credentials to prove its identity for network access authorization.
• PANA Authentication Agent (PAA): The access network side entity of the protocol whose
responsibility is to verify the credentials provided by a PANA client and grant network access
service. In occasions, PAA may not have sufficient information to verify user’s credential and
need to forward it to another entity (Authentication Server).
• Authentication Server(AS): This entity owns information about users and it is able to verify
credentials sent by user through PAA
Enforcement Point (EP): A node on the access network where per-packet enforcement policies are applied.
These policies are applied by PAA after a good authentication.
3.1.5.2 State of art
A PANA implementation is being developed by the Open Diameter Team. The last one is based on version 3
of the draft. UMU is collaborating with this team in these aspects:
• Integration PAA with a Client-side Diameter EAP application. It allows to communicate PAA
with an AS based on Diameter.
• Integration EAP-TLS module with PaC, PAA and Diameter server to allow an authentication
based on X509 certificates.
3.1.5.3 Purpose in SEINIT
To allow flexible and homogeneous authentication regardless the network access technology in use (i.e.
DSL, wireless, etc…). Furthermore, there exists the possibility of interacting with another different
technologies currently used in network access (i.e. IEEE 802.1X).
3.1.5.4 Adaptation and use
Client side PANA protocol should be adapted to small devices. New EAP methods should be developed and
integrate them with PANA to allow different types of authentication. On the other hand, PAA
implementation should be integrated in access routers (as PANA framework draft states) though it will
depend on the final defined scenarios. Finally between PAA and EPs will be needed an interaction to carry
out authentication process. It could be done through an API (when PAA and EP are co-located) or another
protocol like SNMPv3 (PAA and EP are separated).
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 37 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
3.1.5.5 Interaction with other components
PANA deployment will interact with:
• PaC: to allow it to get network access and verify its credentials.
• PAA: to allow verifying PaC credentials. Communication with PaC will be carried out through
PANA protocol. In some cases, PAA must interact with deployed Diameter infrastructure to
verify these credentials.
• EP: to enable access to authenticated PaC.
• Diameter Infrastructure: where AS is placed on and where user’s information is stored.
3.2 Access Control managed with Credentials
3.2.1 EAP Keying Framework
3.2.1.1 Functional description
The EAP keying framework in principal performs the authentication of a client in order to get access to some
network resources. Additionally it can further support the derivation of keying material, which can be used
e.g. for encryption services.
Within the EAP keying framework two main functionalities have to be distinguished,
• the exchange of the required messages, which is done by the EAP basic protocol, and
• the authentication process itself, which is done within one of several possible EAP authentication
methods with different security properties. The information related to these EAP authentication
methods are exchanged within the EAP basic protocol.
As depicted in Figure 15 with the example of a WLAN hot spot, the EAP basic protocol principally
differentiates between 3 involved instances, the supplicant, the authenticator and the backend authentication
server.
Supplicant
Authenticator
Backend
Authentication Server
Figure 15: EAP overview
The supplicant is usually a PC client, which needs to be authenticated in order to gain access to the network.
It uses for its communication e.g. EAP over PPP or EAP Over LAN. The latter variant is currently deployed
in most WLAN networks.
The authenticator can have two different modes of operation. First it can act as the peer to the supplicant
concerning the EAP protocol, that is, the authenticator will have in this case full EAP functionality. A second
alternative for the authenticator is to act in a pass-through mode, that is it only passes the EAP messages
from the supplicant to the backend authentication server and vice versa, but blocks all other messages.
Authenticators could be switches or router, or as in the example case above WLAN access points.
As already mentioned above, the backend authentication server supports an authenticator, which runs in the
pass-through mode. In this case it exchanges EAP messages with the supplicant and performs the relevant
tasks required for the authentication of the client. A backend authentication server could typically be realized
by a RADIUS server.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 38 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
The basic EAP protocol therefore could run between supplicant and either authenticator or backend
authentication server. For this purpose EAP defines 4 different packet formats, EAP request, EAP response,
EAP success and EAP failure. While the first both packet formats are used to exchange authentication
material between the respective EAP peers, the last both indicate the successful or unsuccessful completion
of the authentication process.
Within this basic EAP protocol, different EAP authentication methods can be carried, like EAP MD5, EAP
TLS, EAP TTLS, EAP PEAP or EAP LEAP. Depending on the selected EAP authentication method a
different number of EAP request and response messages will be exchanged between the EAP peers, until the
EAP method either success or fails. It is exactly the selected EAP authentication method, which mainly
determines the strength of the authentication. For example using EAP MD5 no mutual authentication
between both EAP peers will be performed, but only the authenticator will authenticate the supplicant.
Furthermore with EAP MD5 no keying material will be derived on both sides. Using e.g. EAP TLS, a mutual
authentication based on certificates will be done between supplicant and authenticator. Furthermore keying
material can be derived on both sides and used e.g. for encryption services.
3.2.1.2 State of art
The EAP protocol is already supported by the majority of operating systems, and made its way also to many
WLAN products. As an open source implementation the Open Diameter project offers code for the EAP
client and the EAP authenticator. This source code should run on different UNIX versions as well as on
Windows operating systems with Adaptive Communication Environment (ACE) support.
3.2.1.3 Purpose in SEINIT
Authentication is a key technology required for the provision of secure services. Before being able to do any
kind of shared-key encryption between two partners they usually have to mutually authenticate their
identities in advance. In some scenarios the authentication of the peer identity itself is already the only
security service required, e.g. for the exchange of routing information or the provision of network access.
The EAP keying framework is frequently used today in order to provide this authentication, e.g. for the
provision of secure access to wireless LAN networks. Therefore EAP could be used in SEINIT for the secure
deployment of WLAN hot spots. As most EAP types like EAP TLS, EAP TTLS, EAP PEAP or EAP LEAP
support the derivation of keying material, EAP could also provide the basis for encryption service in wireless
LANs. Furthermore the PANA protocol currently developed for providing a network access authentication
service over IP makes use of the EAP keying framework.
3.2.1.4 Adaptation and use
EAP will be required in order to demonstrate the PANA functionality. PANA, a link layer agnostic transport
protocol for network access authentication information, makes use of EAP for performing the different
authentication methods, such as EAP MD5, EAP TLS or EAP TTLS. Furthermore EAP can be used directly
on the media like WLAN for doing a link layer dependent authentication, as it could be useful in secure
WLAN hot spots.
3.2.1.5 Interaction with other components
EAP just defines an authentication framework supporting different authentication methods. In order to
deploy EAP, it additionally requires a transport protocol for carrying the EAP packets. One solution
currently under standardisation is the PANA protocol, which run on top of UDP / IP and is therefore link
layer agnostic. Other potential transport protocols are PPP or EAP Over LAN, which is used in the majority
of WLANs.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 39 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
3.2.2 SAML Access Control
3.2.2.1 Functional description
SAML is widely being used in projects requiring entities authentication and/or authorization to access
resources. UMU is deployment a SAML authority to offer authentication/authorization services, this SAML
authority is based on HTTP and SOAP protocols and can be used to offer security to web services and access
control applications. An application example of this authority is described in the next figure:
AAA
EE
AP
LA N
SAML
Authz
router
W AN
Figure 16: SAML example
In this example an End Entity (EE) requests network access (the network is the resource to be granted by the
entity) sending its credential (X509 certificate or SAML assertion) to the Access Point (AP) which forwards
it to the AAA server (for example, using 802.1x/EAP-TLS). This server consults the SAML authority to
ensure the End Entity has the right permissions to grant access to the network. SAML provides the EE’s
assertions to the AAA server which take the decision to grant or deny the access.
This scenario can be improved using an already defined SAML profile. In this case, in a first step, the EE
accesses to the SAML Authority (and only to this entity, for example, using filtered VLANs). End entity
could now request SAML authorization statements that will present to the AAA server. AAA server can now
decide whether accept or reject the end entity’s request. Note that in this last case AAA server does not
interact with the SAML Authority, only end entities do it.
SAML authority can also be used to access other services than network access, for example, to deploy Single
Sing On scenarios or B2B secure applications. In this case, the EE requests a service which have to obtain
the user’s credential. The credential can be obtained from the own user or accessing to a SAML authority to
request them. Once the service has the user’s credential it can grant or deny access to the resource.
3.2.2.2 State of art
Actually, UMU is implementing the SAML Authority like a security service provider entity and deploying
the network access control like a example scenario which allows interaction of a wide group of technologies:
EAP, AAA, PKI, SAML, etc..
3.2.2.3 Adaptation and use
Once released, SAML authority will can be used to deploy security scenarios requiring authorization
mechanism like SSO federations, network access control points or advanced applications in access control
and security.
3.2.2.4 Interaction with other components
As previously commented, SAML authority could interact with a AAA server, acting like a authorization
client, must interact with a PKI to provide public key authentication and could be used by every service
requiring end user authorization inside a secure domain.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 40 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
4 Preliminary implementations to secure E2E service
architectures
4.1 E2E security mechanisms
4.1.1 Distributed infrastructures
4.1.1.1 Functional description
Within the Internet community, both resources and data are distributed in a wide networked area with
components administered locally and independently. Scientific applications, as grid computing, and
multimedia applications, as knowledge management, must share and coordinate the use of large quantities of
data and remote computational resources.
These real-time distributed software applications need a secured infrastructure providing guaranteed network
services as availability, reliability and scaled performance.
The E2E security mechanisms concern not only the relationship between the service providers and the enduser, but also the virtual community of service providers. The heterogeneity of resources and the dynamic
nature of processes increase the difficulties of security management of such applications.
A secured protocol is required to enable communication between applications.
Distributed applications can communicate using Remote Procedure Calls (RPC) between objects like DCOM
and CORBA, but security policies implemented in firewalls and proxy servers usually block such RPC
traffic.
A solution is to communicate over HTTP and use SOAP (Simple Object Access Protocol). SOAP is a simple
XML based protocol designed to let applications exchange information over HTTP. These applications can
run on different operating systems, with different technologies and programming languages.
4.1.1.2 State of art
The management of services access in a distributed infrastructure raises several issues due to the
heterogeneity of platforms, organisations and APIs.
The integration of the different features in a distributed infrastructure is generally performed through custom
solutions, that finally makes very tightly coupled applications. We face the lack of standard way to be able to
manage the execution of the different services provided by the platform.
THC has specified and developed in Java language an intermediation architecture for services access
management in a distributed infrastructure. This middleware offers relevant functionalities to match these
requirements:
Distributed services context
Easy accessibility to service
New service deploying assistance
Optimal services interoperability
Communications facilities
We use the standardised and widely used SOAP Protocol over HTTP for the control flow.
A scripting language has been developed, and also a processor for that language
A prototype has been developed as a proof of concepts for the application of SOAP, and scripting/processes
for the services access.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 41 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
4.1.1.3 Purpose in SEINIT
In WP5 - Adaptation & Integration of the Applications - we select distributed IPv6 enabled applications to
validate the SEINIT security framework. Distributed applications are distinguished from traditional clientserver applications by their complex communication structure and their large-scale, heterogeneous
environment. We need to provide specific security mechanisms to administrate and enable trusted peer
communications.
4.1.1.4 Adaptation and use
A distributed infrastructure for intermediation can be used to federate a set of web-services.
From the user point of view, this infrastructure provides services for multimedia support, virtual community
support and services execution management support.
From the administrator point of view, this infrastructure provides a distributed security model that fit
distributed environment security requirement and related service supervision and administration.
4.1.1.5 Interaction with other components
The modules dedicated to scripting/processes for the services access should interact with the policy
management system from the security domain.
The control flow messages exchanged in the distributed infrastructure should rely on the information
provided by the IPv6 routing security mechanisms and the IP signaling.
4.1.2 Adaptive content
4.1.2.1 Functional description
Exchanging information in a heterogeneous environment requires that information structure and content
must be flexible enough to be directly suitable for the terminal before being delivered to the person or
service addressed.
The goal of an adaptive content system is to avoid developing as many versions of a same application as
necessary to fit end user equipment requirements, network characteristics or user profiles. This system is a
middleware network infrastructure in charge of adapting the way to present and/or filter the content of the
information data flow by running routines on data flows according to configuration rules.
For example, we can adapt HTML pages to fit small screen size devices, modify the QoS level of a video
streaming transmission, filter information relevant only for a particular user profile.
The use of a policy-based implementation provides generic components and allows the end-user to define a
set of coherent rules to match his/her needs.
4.1.2.2 State of art
Adaptive content modules already exist inside applications, e.g. browser or mailing-box. The user is
provided with a set of options that he/she can configure to fit his/her needs.
We face two limits with such an implementation: the end-user is dependent from a software provider and the
network is crowed by unnecessary or unwanted data flows.
THC has developed in Java language a generic policy-based component to deliver adaptive content. This
component is called a content adaptation module (CAM). The CAM can be implemented on the end-user
device or on a remote service provider.
A first prototype is available and consists in a CAM plugged into a remote proxy that adapts the image size
and resolution according to the terminal screen.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 42 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
To simplify the treatment of the data flow, we define a single format representing an elementary block of
information content, called a cell. This capsule holds the information data itself and a set of properties, which
characterizes the nature and the state of the encapsulated content. On each cell, a specific service is applied
according to the rules edited in the policy.
The architecture of the CAM is detailed in Figure 17: Detailed Architecture of a generic CAM. The cell
structure and the policies are described using XML with a specific DTD.
Libraries of Resources
Cell
parsers
Policies
Services
Session Management
Session
Factory
External Communication
Events
generation
Messages
Management
CAM State Management
Session
Scheduler
CAM
State
Profile
Management
Process
Cell Management
Cell Capture
& Generation
Content
Extraction
Statistic Management
Statistic
Tools
Statistic
Engine
scheduler
Figure 17: Detailed Architecture of a generic CAM
4.1.2.3 Purpose in SEINIT
As explained previously, the content adaptation is generally processed at the application level, a domain
where the user cannot really define his/her security policy because of the pre-existing implementation from
the software providers.
In the context of the SEINIT project, we defined the concept of a virtual ring, a quarantine zone to filter the
data flow for a security domain. An adaptive content module with a security-oriented policy could manage
this security zone.
4.1.2.4 Adaptation and use
The adaptive content module should be flexible enough to be implemented in any devices in the SEINIT
framework (terminal, remote server, edge router…).
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 43 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
The first issue is to implement the adaptive content module into a set of basic building blocks (depending of
the data flow and the targeted devices).
The second issue is to specify the security-oriented policy and the cell structure depending of the selected
application.
4.1.2.5 Interaction with other components
As the content adaptation module is applying a set of rules from a pre-established policy, this module should
interact with the policy management system from the security domain.
To parse the data flow into a suite of relevant cells, the content adaptation module should rely on the
information provided by the IPv6 routing security mechanisms and the IP signaling.
4.1.3 QoS
Quality of Service in one of the critical function that cannot easily realised for the real time applications
across the IP networks. There are multiple schemes developed in the past such as intserv (RSVP) and
Diffserv. The latter is used for the aggregated traffic, in many cases, but RSVP is not a scalable protocol.
To improve the situation in IPv6 networks, the 20 bit flowlabel has been defined, to control the QoS at the
flow level of information stream.
Quality of Service is defined to mean that the Flow (flow or composite flow) defined by a Flow Label is
processed so as to achieve a particular rate, delay priority, precedence priority, and over-rate tolerance (burst
tolerance). This requires a discard and scheduling process within the routers that treats each Flow separately,
keeping a Flow in order, and maintaining as well as possible the requested QoS parameters (rate, delay,
precedence, and burst tolerance). Different Flows within a CoS may be treated differently to achieve the QoS
objectives. Typically, interactive streaming media like voice and video need QoS to achieve low delay
variance and no loss. Also, TCP Flows may benefit significantly from QoS rate control and feedback so that
the source can quickly get to and maintain high throughput over high delay or high bandwidth paths.
4.1.3.1 State of the art status of flowlabel definition
Though 20 bit flowlabel has been defined, there were no real discussions so far. However, with the technical
and market push for IPv6 networks, the standards work has been taken up recently to stadndardise this field
and develop specifications on how to use this field
This specification under development applies to any IPv6 network of routers. All the routers in the network
need not support this QoS option but those that do support the option must have routing information, either
manually configured or exchanged in a routing protocol that identifies those adjacent routers that do support
the specified option. These QoS capable routers can then identify routers that support this option and either
pass Flows that have a QoS option field to those routers that can support the option or else clear the QoS
field. This insures that a router that cannot support the QoS option will not pass the option along without
taking responsibility to support the QoS.
There may be gateways in the network (like encryption devices) that consolidate many Flows into one Flow
in order to reduce network complexity or to maintain traffic security. This specification applies between such
gateways and should also be used on the other side of such a gateway, from the source to the gateway or the
gateway to the destination. However, when such consolidation is done it should set the QoS request of the
composite Flow so as to support the QoS of all the incoming Flows.
4.1.3.2 Network Architecture
Any IPv6 network can use this QoS option from the end source to the end destination as shown in Figure 1.
In the figure the source is a server sending a stream or file to a terminal. The source adds the QoS option to
request the QoS desired with user selected guaranteed rate and/or network determined available rate. The
packet travels across the user’s local network (Area 1). There may then be an encryption device to separate
Area 1 from the general network. There are two QoS-capable options at the encryption device:
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 44 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
A new IPv6 packet header is added with the source address of the Encryptor, the destination address of the
Decryptor, a new flow label (either the original one or a translation of the original one), a QoS option field
(either the original one or a masked subset of the original one), and the encrypted original packet.
A new IPv6 packet header is added with the source address of the Encryptor, the destination address of the
Decryptor, a new flow label that stands for a group of incoming flows, a QoS option field that reflects the
combined requirements of the combined flows, and the encrypted original packet.
In case one, the flow will retain its individual QoS across the entire network. This will provide the maximum
capability to the end user and the maximum efficiency of the network. In case two, security may dictate that
many flows be combined into one stream. This will impact network efficiency and may be difficult to
administrate due to the necessity of allocating bandwidth at the Encryptor. Of course, the Encryptor could
eliminate the QoS option altogether, but then no QoS will be able to be setup across the network.
Internet
Router
Router
Area 2
Area 3
Encryptor
Encryptor
Area 1
Area 4
Router
Router
1 De
Source
Destinatio
Figure 18: IPv6 network with QoS options
After encryption, the packet traverses routers in Area 2, a network link, routers in Area 3, and arrive at a
second Encryptor for decryption. Here the original packet is decrypted with its original flow label and QoS
request and is passed on through Area 4 to the destination. The QoS request will have been processed by all
the routers in the path to determine what available rate can be assigned fairly to the flow and if the requested
guaranteed rate is available. The destination will receive the QoS request modified to what is available. It
returns a packet to the source with this information. The source then adds this confirmed QoS to its next
packet as a confirmation. This allows all the routers in the forward path to release any resources reserved.
The source then proceeds to send at the agreed rate for up to 128 packets. Then it must re-request its
available rate so the network can adjust quickly to load or capacity changes.
The entire process allows the establishment of flows at the maximum rate the network can support without
congestion packet losses.
4.1.3.3 IPv6 Flow Label Specification
The 20-bit Flow Label field in the IPv6 header is used by a source to label packets of a flow. A Flow Label
of zero indicates that there is no flow control with the associated packets. Packet classifiers use the triplet of
Flow Label, Source Address, and Destination Address fields to identify which flow a particular packet
belongs to. Packets are processed in a flow-specific manner by the nodes that have been set up with flowspecific state.
The Flow Label value set by the source is delivered unchanged to the destination node(s).
The use of the Flow Label field does not necessarily signal any requirement on packet reordering. If an IPv6
node is not providing flow-specific treatment, it will ignore the field when receiving or forwarding a packet.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 45 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Flow Labeling Requirements
To enable Flow Label based classification, source nodes assigns each unrelated transport connection and
application data stream to a new flow. The source node may take part in flow state establishment methods
that result in assigning certain packets to specific flows. If source node does not assign any Flow Label, the
default value is set to zero.
To enable applications and transport protocols to define what packets constitute a flow, the source node
provides means for the applications and transport protocols to specify the Flow Label values to be used with
their flows.
The source node selects unused Flow Label values for flows not requesting a specific value to be used.
A source node will not reuse Flow Label values it is currently using or has recently used when creating new
flows (during atleast next 120 seconds).
4.1.3.4 Security issues related with the use of Flow label
This security issues raised by the use of the Flow Label, primarily the potential for denial-of-service attacks,
and the related potential for theft of service by unauthorized traffic
Theft and Denial of Service
Since the mapping of network traffic to flow-specific treatment is triggered by the IP addresses and Flow
Label value of the IPv6 header, an adversary may be able to obtain better service by modifying the IPv6
header or by injecting packets with false addresses and/or labels. Taken to its limits, such theft-of-service
becomes a denial-of-service attack when the modified or injected traffic depletes the resources available to
forward it and other traffic streams.
Since the treatment of IP headers by nodes is typically unverified, there is no guarantee that flow labels sent
by a node are set according to the recommendations in this document. Therefore, any assumptions made by
the network about header fields such as flow labels should be limited to the extent that the upstream nodes
are explicitly trusted.
Since flows are identified by the 3-tuple of the Flow Label and the Source and Destination Address, the risk
of theft or denial of service introduced by the Flow Label is closely related to the risk of theft or denial of
service by address spoofing. An adversary who is in a position to forge an address is also likely to be able to
forge a label, and vice versa.
There are two issues with different properties: Spoofing of the Flow Label only, and spoofing of the whole 3tuple, including Source and Destination Address.
The former can be done inside a node which is using or transmitting the correct source address. The ability
to spoof a Flow Label typically implies being in a position to also forge an address, but in many cases,
spoofing an address may not be interesting to the spoofer, especially if the spoofer's goal is theft of service,
rather than denial of service.
The latter can be done by a host which is not subject to ingress filtering or by an intermediate router. Due to
its properties, such is typically useful only for denial of service. In the absence of ingress filtering, almost
any third party could instigate such an attack.
In the presence of ingress filtering, forging a non-zero Flow Label on packets that originated with a zero
label, or modifying or clearing a label, could only occur if an intermediate system such as a router was
compromised, or through some other form of man-in-the-middle attack. However, the risk is limited to
traffic receiving better or worse quality of service than intended.
Since flows are identified by the complete 3-tuple, ingress filtering will mitigate part of the risk. If the
source address of a packet is validated by ingress filtering, there can be a degree of trust that the packet has
not transited a compromised router, to the extent that ISP infrastructure may be trusted. However, this gives
no assurance that another form of man-in-the-middle attack has not occurred.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 46 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Applications with an appropriate privilege in a sending host will be entitled to set a non-zero Flow Label.
Mechanisms for this are operating system dependent. Related policy and authorization mechanisms may
also be required; for example, in a multi-user host, only some users may be entitled to set the Flow Label.
IPsec and Tunneling Interactions
The IPsec protocol does not include the IPv6 header's Flow Label in any of its cryptographic calculations.
Hence modification of the Flow Label by a network node has no effect on IPsec end-to-end security, because
it cannot cause any IPsec integrity check to fail. As a consequence, IPsec does not provide any defense
against an adversary's modification of the Flow Label (i.e., a man-in-the-middle attack).
IPsec tunnel mode provides security for the encapsulated IP header's Flow Label. A tunnel mode IPsec
packet contains two IP headers: an outer header supplied by the tunnel ingress node and an encapsulated
inner header supplied by the original source of the packet. When an IPsec tunnel is passing through nodes
performing flow classification, the intermediate network nodes operate on the Flow Label in the outer
header. At the tunnel egress node, IPsec processing includes removing the outer header and forwarding the
packet using the inner header. The IPsec protocol requires that the inner header's Flow Label not be changed
by this decapsulation processing to ensure that modifications to label cannot be used to launch theft- or
denial-of-service attacks across an IPsec tunnel endpoint.
When IPsec tunnel egress decapsulation processing includes a sufficiently strong cryptographic integrity
check of the encapsulated packet, the tunnel egress node can safely assume that the Flow Label in the inner
header has the same value as it had at the tunnel ingress node.
Security Filtering Interactions
The Flow Label does nothing to eliminate the need for packet filtering based on headers past the IP header, if
such filtering is deemed necessary for security reasons on nodes such as firewalls or filtering routers.
4.1.3.5 SEINIT relevance
Telscom has implemented a proprietory Flow Label mechanism, but does not follow the present version of
the standard. Hence, some additional work has to be done to conform to new standards taking into account
the security issues discussed above. These will be done by following the ongoing standards and
implementing the latest specifications.
4.1.4 Policy management
4.1.4.1 Functional description
The goal of policy-based management is to enable network, service and application control and management
on a high abstraction layer. The administrator specifies rules that describe domain-wide policies independent
of the implementation of the particular network node, service or application. It is then the policy
management architecture that provides support to transform and distribute the policies to each node and thus
to enforce a consistent configuration in all involved elements, which is a prerequisite for achieving
end-to-end security services, for example.
Use of policies is an intrinsically layered approach allowing several levels of abstraction. There can be, for
example, general policies expressing an abstract business goal, and on the other end there can be policies that
express a rather specific, device or service dependent rule.
Policy rules are independent of a specific device and implementation, but define in abstract terms a desired
behavior. They are stored and interpreted by the policy framework, which intent to provide a consistent
behavior in all affected policy enforcement points. The main functions of a policy management architecture
are:
• Monitoring: on-going active or passive examination of the network, its services and applications
for checking its status and whether policies are being satisfied or not
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 47 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
• Decision-making: to compare the current state of the communication system to a desired state
described by a policy (or a set of them) and to decide how the desired state can be achieved or
maintained
• Enforcement: to implement a desired policy state through a set of management commands
4.1.4.2 State of art
UMU has designed and implemented a first prototype of a policy-based management system, named
UMU-PBNM (University of Murcia Policy-Based Network Management). The UMU-PBNM system aims to
provide a security framework for the management of policies in IP networks. It is based on the use of IPsec
and public key cryptography as a way to deal with the security concerns associated with today’s networked
environments. It is also based on the IETF approach to network policies, which is attempting to define the
basis for a multi-vendor networking environment supporting policy control mechanisms.
The UMU-PBNM policy management framework is composed of two main elements: one XML policy
language based on the IETF PCIM standard information model, and one distributed policy management
architecture, as depicted in Figure 19.
Figure 19: General View of the UMU-PBNM Architecture
Figure 19 shows the different components of this architecture: policy consoles, policy management tools
PMT–, policy decision points –PDP–, policy enforcement points –PEP–, network devices and application
servers; it also shows the protocols in use: HTTPS, an UMU-defined PMT-PDP communication protocol
named PSIP –Policy Server Interchange Protocol–, COPS, COPS-PR, and SNMP or the proprietary interface
in use by the end node.
4.1.4.3 Purpose in SEINIT
In the context of the SEINIT project, the concept of policy plays an important role. In fact, the security
models being addressed in this project can be implemented through a policy paradigm, which could provide
the level of dynamicity, flexibility, and interoperability required by the SEINIT framework.
Moreover, the idea of different (private, semi-private, semi-public, etc.) infospheres matches well with the
concept of various policies to be applied in different environments by both the network providing services
and the users accessing to them.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 48 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
4.1.4.4 Adaptation and use
Although several kinds of security policies can be initially envisaged in the SEINIT framework, a policy
management architecture and a set of policy languages able to describe and manage at least the security
functionalities provided by the network, and the security requirements imposed by the end user (or the
application or service being used by him/her) could be considered as a first approach for the dynamic
provision of security policies in SEINIT.
Several components inside this management architecture need some additional work. It is the case of the
specification of the set of policy languages to be used inside SEINIT, and the design of procedures for policy
validation and refinement of high-level policies into device configurations, for example.
Moreover, the integration of the policy management architecture in a multi-domain environment could be
considered of interest. For this, the integration with some existing tools, such as the DVC (Dynamic VPN
Controller) developed by NRNS Inc. upon contract of Defence R&D Canada (DRDC), and the X-Bone
overlay manager from ISI, represents an interesting line to analyse.
4.1.4.5 Interaction with other components
A policy management system usually needs to interact with a public key infrastructure, which acts as its trust
management system. In this particular case, a certificate lifecycle management protocol, as CMC or CMP, is
required. Moreover, the definition of multi-domain scenarios may also require the establishment of trust
relationships (i.e. based either on a hierarchy, or peer-to-peer cross-certification, or the existence of a Bridge
CA) between different PKI implementations, and the existence of certificate path building and validation
services.
On the other hand, this system may also benefit with the integration with a privilege management
infrastructure (PMI), which can provide the required attribute certificates and/or SAML assertions required
by services, network administrators, and end users to prove, for example, their group membership (e.g. a
certain service can be accessed or not, depending on the group to which one particular user belongs).
4.2 Honeypot
4.2.1 Dynamic IPv6 honeypot
4.2.1.1 Functional description
« A honeypot is a security resource whose value lies in being probed, attacked or compromised »
Honeypots are a highly flexible tool that can be applied to a variety of different situations:
Use to deter attacks (sane goal as firewall).
Use to detect attacks (same goal as APS)
Use to capture and analyze Worms
Use to study blackhat community behaviour
Basically, regarding their purpose, they can be classified in two major categories:
Production honeypot: they protect an organisation
Research honeypot: they are used to learn
A dynamic honeypot learns from its environment and according to its security policy, it
automatically determines how many honeypots to deploy, how to deploy them, and what they
should look like to blend in with the environment. Even better, the deployed honeypots change and
adapt to your environment.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 49 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Several kind of components will be needed to achieve the targeted honeypot architecture describe in D2.3
Thus a honeypot can virtually be build we any kind of software, we propose to use the most popular tools
used by the honeynet project.
Although it is not an official standard, the honeynet community define a kind of charter to state the
definitions, requirements and standards for a Honeypot1, we used it as a basis (with minor modification) for a
first classification of honeypot components.
CATEGORY
Honeypot services : Simulate some fake service and behaviour to
lure the blackhats
Data control : Once a Honeypot is compromised, we have to contain
the activity and ensure the honeypots are not used to harm non
Honeypot systems. Data Control always takes priority over Data
Capture
Data capture : Capture all activity within the Honeypot and the
information that enters and leaves the Honeynet, without blackhats
knowing they are being watched
Data analysis : Analyse the collected using various algorithm and
define action according to some security policy
Dynamic configuration : the honeypot can “learn”from is
environnement (network, OS, application) and dynamically
configure itself using this information and its security policy
COMPONENT(S)
HONEYD
NETFILTER/IPTABLE
SNORTINLINE
SEINIT IDS
SEINIT IDS
SEINIT IDS
pOf, NMAP, SEINIT IDS
SEINIT HONEYPOT
CONFIGURATION MODULE
HONEYD
Honeyd is a small daemon that creates virtual hosts on a network. The hosts can be configured to run
arbitrary services, and their personality can be adapted so that they appear to be running certain operating
systems. Honeyd enables a single host to claim multiple addresses on a LAN for network simulation.
Honeyd supports service virtualization by executing Unix applications as subsystems running in the virtual
IP address space of a configured honeypot. This allows any network application to dynamically bind ports,
create TCP and UDP connections using a virtual IP address
Honeyd can be used to create a virtual honey net or for general network monitoring. It supports the creation
of a virtual network topology including dedicated routes and routers. The routes can be attributed with
latency and packet loss to make the topology seem more realistic
1
The Honeynet project : ### Honeynet Definitions, Requirements, and Standards ### - http://project.honeynet.org/alliance/requirements.html
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 50 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Figure 20: How Honeyd Works
NETFILTER / IPTABLE
Netfilter and Iptables are building blocks of a framework inside the Linux 2.4.x and 2.6.x kernel. This
framework enables packet filtering, network addresss [and port] translation (NA[P]T) and other packet
mangling.
Netfilter is the system compiled into the kernel which provides hooks into the IP stack which loadable
modules (iptables is one) can use to perform operations on packets.
Iptables is a generic table structure for the definition of rulesets. Each rule within an IP table consists out of
a number of classifiers (iptables matches) and one connected action (iptables target).
Iptables is split into two parts; The user-space tools and the kernel-space modules. The kernel-space modules
are distributed with the main kernel, and you compile them as you would any other module, be it sound
drivers, a filesystem or USB support. There is the main ip_tables module, as well as modules specifically for
NAT, logging, connection tracking and so on. These modules perform the appropriate function on the
packets which they get sent by netfilter, depending on the rules which they have in their rule-list, or chain.
The user-space iptables code comes in the form of a binary called ‘iptables’, which is distributed separately
from the main kernel tree, and is used to add, remove or edit rules for the modules.
4.2.1.2 State of art
HONEYD
Honeyd is open source software released under GNU General Public License. Honeyd is maintained and
developed by Niels Provos.
Actually honeyd is a well-known product in the honeynet community. It is a core component of numerous
honeynet project.
Kyos use this component in its honeynet architecture, the main actual limitation is that this component is not
fully ipv6 compliant.
NETFILTER / IPTABLE
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 51 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Iptables is a widely use firewall technology, available in all recent linux distribution . Around this
framework, there’s a lot of useful tools that are available to provide some better configuration capabilities
(like firewall builder), statistical analysis and so on.
Kyos use this framework in several area :
As a gateway in bridging mode, within our honeynet architecture
As an ipv6 compliant firewall gateway, for ipv6 testing activity
on stand alone critical hosts (like anti-spam gateway, dns or webserveur)
And thus we can provide several configuration file regarding various use of this component.
The actual main limitation is regarding access control at the application layer. Iptable can work with several
security proxies, like the TIS framework. However, this combination can degrade seriously the firewall's
performance.
4.2.1.3 Purpose in SEINIT
At this stage the scope is not to work on all the honeypot technologies and purpose, but only on what this
technology can bring to enhance the SEINIT architecture.
The honeypot will be used in its ability to improve intrusion detection capabilities. It will be build more like
a production honeypot (with less complexity and interaction than a research honeypot), with some
enhancement do became dynamic, reconfigurable, and available in heterogeneous environment
In other word, it will be a kind of lure or burglar alarm which help in defining a level of threat or give
interesting information to trust’s algorithm needed in some authentication scenario for example.
HONEYD
We’ll have to demonstrate several instantiations of honeypot depending on what the virtual ring defined in
WP2 is. In some case the honeypot should be a single application, in other case a host or even a network.
Honeyd with its ability to create virtual host and virtual network is a powerful component to cope with all
these scenarios.
NETFILTER / IPTABLE
The honeypot architecture defined in SEINIT will use this component as a basic framework for data control.
It can also be used for all the various network access control services needed within the SEINIT architecture
4.2.1.4 Adaptation and use
HONEYD
Honeyd will be used as major component to simulate fake service, host or networks.
Actually honeyd run well under linux and BSD.
The main adaptation consist of some port of the code to ipv6 and the addition of script specific to simulate
SEINIT network, operating system and application chosen for the scenario.
NETFILTER / IPTABLE
This component can be used with few adaptations; it is already ipv6 compliant and provides most of the
needed functionalities. The main addenda will be an interface with the SEINIT Policy Management
Framework.
4.2.1.5 Interaction with other components
This component will have to interact with most of the SEINIT IDS components to provide data capture and
data analysis functionalities.
It will also have the following interfaces and interactions:
An Interface do be activated by SEINIT DECISION or ACTION modules (SEINIT middleware )
An Interface to understand SEINIT security policy (SEINIT Policy Management Framework)
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 52 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
An Interface to send a message for the SEINIT decision engine (SEINIT middleware)
An interface to collaborate with other SEINIT compliant IDS or Honeypot on the SEINIT session
path
4.2.2 Wireless Honeypots
4.2.2.1 Functional description
A wireless honeypot is a wireless resource that waits for attackers or malevolent users / traffic to come
through on your wireless infrastructure. The idea would be to monitor and learn from the attack so steps can
be taken to secure / protect your network.
4.2.2.2 State of art
Honeypots are becoming more developed as new hacker techniques are being discovered. Wireless network
clients are a lot more accessible than wired clients, so the idea of a wireless honeypot will bring new
demands to this technology. At the moment a honeypot can be deployed on a wireless network using the
same software as used for wired networks, but because wireless networks are used differently and are
becoming more accessible, new techniques need to be developed in order to listen and record wireless based
activity and attacks. There are issues also to do with layer 2 detection where this layer is now more easily
accessible, where before direct access inside the Ethernet cabling was needed. There are a few useful tools
out at the moment, such as FakeAP that will simulate thousands of access points, so that the attacker must
attempt to attack all of them to find the real one.
4.2.2.3 Purpose in SEINIT
The wireless environment needs to be secure and gaining experience as to how these systems can be
compromised will help develop tactics to help counter attacks.
4.2.2.4 Adaptation and use
Honeyd and Snort-Inline can be modified to be usable in the wireless case to detect wireless specific attacks.
New rules will need to be created and some existing rulesets will have to be modified for the wireless case.
The scenarios we intend to investigate will vary depending on security requirements of the network
resources. Firstly unsecured wireless access points, with just one machine behind it, to detect very basic
attacks, then WEP-protected access points to provide a more realistic environment for experienced attackers,
then to a full network of machines behind the access point. This will allow for research into wireless
honeypot services to create more realistic environments.
4.2.2.5 Interaction with other components
Our wireless honeypot could be configured to report to the SEINIT Policy Management Framework system
where by results produced could in turn affect other security components characteristics. Our honeypot will
be deployed with interaction to the wired network IDS kept in mind. Work being done on IPv6 Honeypots
and dynamic Honeypots will tie directly into this component
4.3 IDS
4.3.1 Snort v6 and wireless IDS
4.3.1.1 Functional Description
An Intrusion Detection System is used to make security professionals aware of packets entering and leaving
the monitored network and give them a better understanding of activity on the network. Intrusion Detection
Systems come in a variety of forms, host based IDS, network based IDS and hybrid IDS which is a mixed
version. Host based IDS are installed on the client machines of a network and monitor traffic and system
activity directly effecting that machine, and can communicate with a central server. Network based IDS
monitor traffic flowing to and from all clients on the network and no upgrade to client machines is needed.
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 53 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
Snort v6
Snort is a misuse-based lightweight network intrusion detection system, capable of performing real-time
traffic analysis and packet logging on IP networks. It can perform protocol analysis, content
searching/matching and can be used to detect a variety of attacks and probes, such as buffer overflows,
stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more. Snort uses a
flexible rules language to describe traffic that it should collect or pass. Snort has a real-time alerting
capability as well, incorporating alerting mechanisms for syslog, a user specified file, a UNIX socket, or
WinPopup messages to Windows clients. This allows for many different possibilities in alerting a sysadmin
to suspicious activity taking place e.g. via SMS messages. Snort is signature based and it requires that
signatures are available in the public domain so that new threats can be quickly alerted to users.
Wireless IDS
For a wireless-IDS there are two types of attacks: IP-based and 802.11- or wireless-based. To cope with IPbased attacks, there is no special treatment in a wireless network. We may just add a NIDS behind our
wireless choke point. To detect 802.11-based attacks we need to analyze all 802.11 traffic including the
management frames. The Wireless IDS will look for misuse through MAC-spoofing, rouge Access Points,
DoS Attacks (i.e. DeAuth-Flood), active scanning and other abnormal traffic. For some Attacks, a state
similar to a stateful packet inspection must be kept. Since the 802.11 protocol has numerous security flaws,
there are many possible attacks already on Layer 2 and therefore an IDS which detects those kind of attacks
is very important for a complete security architecture.
4.3.1.2 State of the Art
Snort v6
Snort is at a very mature stage on IPv4 networks and is in beta development for IPv6 networks. With all
systems that are migrated to IPv6 there are new issues to be dealt with that are IPv6 specific, and new threats
need to be catered for. Currently Snort boasts a large amount of functionality, and the aim is to provide
similar functionality for IPv6 networks with added support for new threats and malicious activity that are
associated with IPv6 and IPv4 transition networks, such as tunnelled protocols, v6 tunnelled in v4, and v4
tunnelled in v6. Signatures for IPv6 threats are limited to a degree, and until there is more research done to
generate the signatures, comparable to that of IPv4, Snort v6 will still be in development.
Wireless IDS
As with most enterprise-critical components for wireless networks, the market of Wireless-IDS is still very
small and immature. There is one mature commercial system from Airdefense (www.airdefense.net), which
deals with attacks on Layer 2. Cisco has as part of their Structured Wireless-Aware Network (SWAN)
program a wireless IDS as well. Several other companies have recently released or have announced such
system. In the field of Wireless IDS, it is like in most areas of wireless networks, we have not yet products,
standards, or established best practice approaches for deploying and managing such systems.
There are also some efforts in the OpenSource community to build a wireless IDS. The popular wireless
Scanner/Sniffer Kismet (www.kismetwireless.net) has some limited IDS functionalities built-in. There is
also a Project which works on building a wireless IDS on the base of SNORT (www.snort-wireless.org).
Telscom are working on a Wireless Intrusion Detection and Management System (WimS), which will be an
appliance, based on some of those projects.
4.3.1.3 Purpose in SEINIT
An IDS is a very important element to any security system and its deployment to an IPv6 network is very
worthwhile. IDS in the SEINIT framework is therefore useful for adding security to defend against network
level threats.
4.3.1.4 Adaptation and use
Investigate as to how it can be deployed on general IPv6 infrastructures and SEINIT specific infrastructure
issues can be detected for and allowed for during development. The design of SEINIT specific rule sets to
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 54 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
tackle early-discovered threats to SEINIT infrastructure. Since the signature database so far is limited,
research needs to be done to make this database more substantial. Adapting Snort v6 to the wireless
environment creating a wireless IDS.
4.3.1.5 Interaction with other components
The IDS could be configured to report to the SEINIT Policy Management Framework where by results
produced could in turn reconfigure the Snort system to pay more attention in certain areas, such as increase
logging of certain activity or deny certain activity. There are a number of options for interaction here. Also
interaction with Wireless infrastructure will be an important aspect of this component. For transition
networks there must be mechanisms to detect and analyse the type of traffic being tunnelled, be it 6 in 4 or 4
in 6, this could be communicated to the IDS by way of policy telling it what to expect and what is should be
cautious of. Work done on transition detection will interact with components in section 2.1 Security for
IPv4/IPv6 transition mechanisms
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 55 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
5 Reference
Transition mechanism
[RFC 2893] R. Gilligan and E. Nordmark "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893,
August 2000
[RFC 2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000
[RFC 2766] G. Tsirtsis and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)",
RFC 2766, February 2000
[RFC 3056] B. Carpenter, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001
[RFC 3068] C. Huitema, "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001
[RFC3053] Durand, A., Fasano, P., and I. Guardini. IPv6 Tunnel Broker. RFC 3053, January 2001
[RFC 3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney. "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)."RFC 3315, July 2003.
[MECH] E. Nordmark and R. E. Gilligan "Basic Transition Mechanisms for IPv6 Hosts and Routers", draftietf-v6ops-mech-v2-02, January 2004
[DSTM] Jim Bound, Laurent Toutain, Francis Dupont ..., "Dual Stack Transition Mechanism (DSTM)",
draft-ietf-ngtrans-dstm-07, Expires August 2002
[ISATAP] F. Templin, T. Gleeson ..., "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draftietf-ngtrans-isatap-21, April 16, 2004
[TEREDO] C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo-01,
February 5, 2004 Work in progress
[Security Overview]P. Savola, “IPv6 Transition/Co-existence Security Considerations”, draft-savola-v6opssecurity-overview-02.txt, February 2004
[Security 6to4] C. Savola, P. Patel, “Security Considerations for 6to4”, draft-ietf-v6ops-6to4-security-02,
Mar 2004
[6to4] draft-itojun-ipv6-transition-abuse-01.txt
[Security NAT] Satomi Okazaki, “NAT-PT Security Considerations”, draft-okazaki-v6ops-natpt-security00.txt, Expires: January 2004
[IPSec NAT] Bernard Aboba , “IPsec-NAT Compatibility Requirements”, draft-aboba-nat-ipsec-04.txt, 30
May 2001
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 56 of 57
FP6 IP "SEINIT" - D3.1 Preliminary Implementation & Development Specification
[MIPv4MIPv6] P. Engelstad, "Transitional Integration of Mobile IPv4 and Mobile IPv6”, draft-engelstadngtrans-mipv4-over-mipv6-01.txt, Expires: February 9. 2002
[6to4 MIP] P. Engelstad, “IPv4 over 6to4 and 6to4 mobility”, draft-engelstad-ngtrans-6to4-v4v6-mobility00.txt, Expires: February 2002
IP Security
[SecArch] S. Kent and R. Atkinson, “Security Architecture for the Internet Protocol”, RFC2401
[IPAH] S. Kent, R. Atkinson, “IP Authentication Header”, RFC2402
[IPESP] S. Kent, R. Atkinson, “IP Encapsulating Security Payload (ESP)”, RFC2406
[DOIISAKMP] D. Piper, “The Internet IP Security Domain of Interpretation for ISAKMP”, RFC2407
[ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner, “Internet Security Association and Key
Management Protocol (ISAKMP)”, RFC2408
[IKE] D. Harkins, D. Carrel, “The Internet Key Exchange (IKE)”, RFC2409
[SecRM] R. Thayer, N. Doraswamy, R. Glenn, “IP Security Document Roadmap”, RFC2411
[OAKLEY] H. Orman, “The OAKLEY Key Determination Protocol”, RFC2412
[IKE2] Charlie Kaufman, Editor, “Internet Key Exchange (IKEv2) Protocol”, draft-ietf-ipsec-ikev2-13.txt,
Expires September 2004
QoS
[RFC3697] IPv6 Flow Label Specification
[NGNLAB] Deliverable D6: QoS section
IST-2002-001929-SEINIT - D3.1 v0 - 08/09/2004
Page 57 of 57