securing ipv6.pdf

8/11/2019 securing ipv6.pdf

1/7

Securing IPv6 Network Infrastructure:A New Security Model

Abdur Rahim ChoudharySEGMA Technologies Inc., 8070 Georgia Ave., Suite 402,

Silver Spring, MD 20910, [email protected]

Alan SekelskyIT & Professional Services

Serco North America1818 Library Street, Suite 1000, Reston, VA 20190, USA.

[email protected]

Abstract Nations network infrastructure such as the GlobalInformation Grid (GIG) for the Department of Defense (DoD)and the OneNet for the Homeland Security Department are tran-sitioning to the Internet Protocol version 6 (IPv6) per DoD CIOMemorandum of June 2003 and the Office of Management andBudget memorandum OMB-05-22. There exist IPv6 specific se-curity vulnerabilities in these network infrastructures that needto be mitigated in order to achieve security parity with the exist-ing IPv4 operations. From the perspective of the Homeland Secu-rity technologies, the existence of additional security vulnerabili-ties implies a possibility for two pronged threats. First, the IPv6specific vulnerabilities reduce the security posture of the networkinfrastructure itself; second, other critical infrastructure sectorsthat depend on IPv6 need additional protection. For example, thefuture supervisory control and data acquisition (SCADA) indus-trial capabilities would increasingly use the IPv6 infrastructure,as would the voice communications, the voice and video collabo-ration, and sharing of data such as the image data and surveil-lance and reconnaissance data.

This paper presents three contiguous results. First, it briefly pre-sents the new IPv6 capabilities; second, it presents a brief analy-sis of the security vulnerabilities arising from these capabilities;and third, it presents a new security model for IPv6 network in-

frastructures that has the potential to mitigate these vulnerabili-ties. The new model is based on the end-to-end connectivity thatis restored in IPv6, thus allowing the use of host based security(HBS) systems together with the perimeter security devices.However, the use of HBS complicates the security trust manage-ment. Therefore the third component of the model is introduced,namely a policy based security management (PBSM) approach.The PBSM approach allows the secure deployment of the hostbased security systems. It provides the capabilities needed to spe-cify the trust zones via a set of security policy rules that togetherspecify a trust zone. Hosts belong to one or more trust zones.Accordingly, the host based security policies are derived from thezone security policies for all the zones to which a host belongs.

In addition, the PBSM approach has the potential to support

more sophisticated security capabilities such as a risk adaptiveaccess control and dynamic security response to a changing op-erational picture. The capabilities are needed to enable net-centric security operations.

Keywords-component; IPv6 Security; Security Vulnerabilities; Security Model, Trust zones.

I. I NTRODUCTION The presidential decision directive number 63 on critical in-

frastructure protection (CIP) includes physical as well as in-formation and communications infrastructure. This paper fo-cuses on the protection of the information and communicationssector. This sector is increasingly founded on the Internet Pro-tocol (IP). Memorandum 05-22 from the office of managementand budget requires this sector to transition to IP version 6(IPv6). Accordingly, the civilian federal agencies as well as thedepartment of defense (DoD) are adopting IPv6 for their net-work infrastructure, such as the OneNet in the department ofHomeland Security and the Global Information Grid (GIG) inthe DoD. This encompasses the core networks, the local areanetworks, international partners networks, wired and wirelessnetworks, satellite communications (SATCOM) networks, andtactical operations networks such as those deployed in a battle-field or an emergency response operation. The security of IPv6

protocol is therefore of fundamental significance within theframework of the critical infrastructure protection. The reasonsare many: first, the cyber infrastructure is founded on IPv6;second, the supervisory control and data acquisition (SCADA)capabilities for industrial control and monitoring systemswould increasingly depend upon the cyber infrastructure; third,IPv6 is the basis for vital services such as the voice communi-cations, the voice and video collaboration, and sharing of datasuch as the image data and the surveillance and reconnaissancedata.

This paper focuses on the protection of infrastructure andcommunications sector with respect to IPv6 specific securityvulnerabilities, and proposes a new security model for IPv6network infrastructure to mitigate these vulnerabilities. Themodel is flexible, extensible, and scalable to enable securitymanagement capabilities for the future net-centric operations.

II. IPV6 SECURITY VULNERABILITIES

As analyzed in references [1, 2] most of the vulnerabilitiesare common between IPv4 and IPv6. Additional vulnerabilitiesdo exist [3] that arise because of the changes that were made inIPv6 [4] specification relative to the IPv4 [5] specification.These changes are summarized below:

IPv6 uses a 128 bit address space versus a 32 bit ad-dress space in IPv4.

978-1-4244-6048-9/10/$26.00 2010 IEEE 500


2/7

The IPv6 routers no longer perform packet fragmenta-tion and reassembly; all packet fragmentation and reas-sembly in IPv6 is performed by the sender and receiverhosts.

A new plug-and-play type capability, namely the state-less address autoconfiguration capability, is introducedto automatically configure IPv6 addresses on newnodes, which reduces the administrative burden of ma-nually configuring them. Additional IPv6 protocols areintroduced for this purpose.

The above two changes meant that the use of InternetControl Message Protocol (ICMP) was now required,versus its optional use in IPv4.

Support for extension headers is required in IPv6 net-works. According to the IPv6 specification [4] a fullimplementation must include support for the followingsix extension headers: hop-by-hop options header, des-tination options header, routing header, fragment head-er, authentication header (AH), and encapsulating secu-rity payload (ESP) header. The last two headers are thecomponents of IP security (IPsec) [6] the support for

which is therefore required under IPv6 specification1

.These changes provide powerful capabilities to an IPv6

network infrastructure. However, they also give rise to newsecurity vulnerabilities which we summarize below.

A. Hop-by-hop Options

The hop-by-hop options header can have any number ofhop-by-hop options, and any option can appear multiple times.An attacker can deliberately use inconsistent option values orinvalid options in a hop-by-hop option header. In such situa-tions Parameter Problem ICMPv6 error messages are issuedto the sender. An attacker can burden the routers by floodingwith such maliciously crafted packets, causing a DoS attack.

There is another vulnerability related to the options in ahop-by-hop options header. The header uses Pad1 and PadNoptions and these padding bytes must be zero filled. Howeverthere is no requirement for the receivers or the routers to verifythe correct implementation of that. The options in a hop-by-hopoptions header may therefore serve as a covert communicationchannel. This can happen via non zero filled padding bytes. Itcan also happen because of the pattern in which padding andother options are used. Such a pattern may itself communicatecovert channel information. For example, using multiplePad1s instead of a single PadN, or a PadN followed by a Pad1may communicate information.

1 Subsequently this support was somewhat weakened when IETFIPv6 security architecture downgraded the requirement for the sup-

port of AH from MUST to MAY. The mandatory support for IPsec inIPv6 has sometimes been interpreted, though incorrectly, to mean thatIPv6 is more secure than IPv4. In reality the use of IPsec is equallyavailable for both protocols So that a consensus view today is thatIPv6 is neither more secure nor less secure than IPv4. Dependingupon how seriously one regards the new IPv6 specific security vul-nerabilities, some researchers might argue that IPv6 is less securethan IPv4.

B. Autoconfiguration

State-Less Address Auto Configuration (SLAAC) [7] is adistinguishing feature of IPv6. However, SLAAC also raisesserious security concerns. One of the concerns about SLAAC isits trust model with respect to the network trusting a node thatautoconfigures itself [8]. A node can acquire a link-local ad-dress and subsequently a globally routable address without anyapproval or control. A new IPv6 node that autoconfigures itselfis allowed an unchecked access to the link. This uncheckedaccess is not limited to the local link because a node can subse-quently acquire a global prefix using solicitation and adver-tisement ICMPv6 messages for Neighbor Discovery (ND) [9].Combining the global prefix with the link local address, thenode can construct a globally routable address and start using itwithout any approval or control.

This trust model introduces serious security vulnerabilitiesand possibilities of attacks [8]. As discussed in this reference,there are about a dozen types of attacks that are possible on theautoconfiguration feature of IPv6. A variety of approaches arerequired to mitigate these risks: the on-link ND messagesshould be filtered at the boundary [10]; the SEND protocol[11] should be used to avoid attacks that use address spoofing;and other filtering mechanisms [12, 13] can be applied.

C. Multiple Addresses

IPv6 assigns multiple addresses to an interface which chal-lenges the filtering rules in the firewalls and access controllists. This is because, unlike IPv4, address based filtering is nolonger feasible when these addresses are autoconfigured, andwhen privacy addresses are used (privacy addresses change

periodically). In such cases, a firewall will need to learn all theaddresses dynamically and the filtering rules will need to beautomatically generate-able using sophisticated policy rule-sets. Such capabilities are not available. Therefore simpler for-malisms must be employed that use some kind of identification

tokens instead of addresses in order to identify a host or aninterface. No such identification mechanism is currently de-fined at OSI layer 3.

D. ICMPv6 Filtering

The use of ICMPv4 messages in IPv4 is optional. It is notrequired for normal network operation. Many IPv4 networksecurity administrators block all ICMPv4 messages. This blan-ket blocking is not possible for IPv6 networks because basicIPv6 network operation require the use of ICMPv6 messages.Therefore specific ICMPv6 traffic must be allowed and theIPv6 firewalls must not apply a blanket blocking of ICMPv6messages. Firewalls with the needed IPv6 filtering capabilitiesare not yet available.

Since some ICMPv6 traffic must be allowed, an attackercan use deliberately malformed ICMPv6 packets to cause errorresponses that spuriously utilize network resources. IPv6 sendsthe ICMPv6 messages also to multicast addresses, which offersa potential for DoS attack through packet amplification.

501


3/7

E. IPv6 Tunneling

The specification for tunneling IPv6 via IPv4 [14] has beenanalyzed for security issues [15]. These attacks are made pos-sible because all 6to4 capable routers regard other 6to4 routersand relays as being on-link. The assumed trust between the6to4 routers and relays leads to attacks that can be directed atthe 6to4 networks, IPv4 networks, or IPv6 networks. In addi-tion, meta-threats are also possible in which case some otherattack is laundered hidden into the 6to4 traffic.

F. Future Extension Headers

New extension headers can be added to the IPv6 specifica-tion, and new options can be added to the hop by hop optionsheader. This can impact the security policy of an enterprise.After a security policy has been formulated and deployed, in-troduction of a new IPv6 extension header will make it neces-sary to revise the security policy, its deployment, and the selec-tion of the security tools. The effectiveness of the deployedsecurity policies can be reduced, causing possible security vul-nerabilities.

III. A NEW SECURITY MODEL The previous section shows that there exist serious IPv6

specific security vulnerabilities. If the traditional security mod-

el is used for IPv6, additional security measures will be re-quired in IPv6 networks in order to secure them against thenew set of vulnerabilities, and to achieve an IPv6 security pos-ture that is at parity with IPv4. For this purpose, more capableIPv6 network and security management tools are needed. Thistranslates into additional cost and engineering effort just toacquire security parity with IPv4. If this course is taken, thecurrent limitations such as the handling of encrypted packetsand the application data that exist in IPv4 security would con-tinue in IPv6 as well.

To overcome these limitations one could use a new securitymodel for the IPv6 network infrastructure. There are three addi-tional motivations for this. First, the current security model thatis based on perimeter protection has serious limitations in sup-

porting end-to-end connectivity, tunneling and encryption [16].Second, there is expectation of more challenging security re-quirements [17] that the emerging net-centric operations willdemand. Third, a modified version of the model can potentially

be used to protect the other sectors, than the information andcommunications sector, in nations critical infrastructure. Thelatter point will evolve as the industrial SCADA and Distrib-uted Control Systems (DCS) technologies get adapted to stan-dardization and an ubiquitous IPv6 network infrastructure [18].

Figure 1 below schematically illustrates the new securitymodel for IPv6 network infrastructure. The components of themodel are defined in subsections that follow.

Perimeter BasedSecurity

P ol i c

y S er v

er

DigitalPolicies

PBSM

Host BasedSecurity

End-to-end Connectivity

Policy Flows

Host

Host

E n d t o e n d a d d r e s s a b i l i t y

H o s t B

a s e d

S e c ur i t y

Perimeter BasedSecurity

Figure 1. Figure 1: Schematics and Components of a new IPv6 Infrastructure Security Model

502


4/7

A. End-to-end addressability

The end-to-end addressability in IPv6 networks is the basicenabling feature for this security model. The solid line in figure1 represents the end-to-end addressability between two hosts.The end-to-end concept [19] is rather amorphous, but fromsecurity point of view it means that the endpoints can be di-rectly addressed and they are generally best suited to analyze

the security consequences of the contents of a packet that theysend or receive. Substantial security burden in this model istherefore placed on the end hosts, and the use of host basedsecurity (HBS) measures described in section B are thus neces-sitated.

End-to-end addressability enables the following operationswhich are necessary for the new security model.

The central policy server for a trust zone (see sectionD) can push appropriate digital policies (policy rule-sets expressed in a computer language) to the networkelements within the zone. The server can also send un-solicited policy directives and notification conditions(such as thresholds, bounds, and trap conditions) to thenetwork elements.

Communications are possible for the security auditing part of the policy based security management (see sec-tion E) to request node configuration status and sendnode auditing directives.

Policy decision point (see section E) can request in-formation on the local decisions made by the node.

These are unsolicited communications. They are well sup- ported in IPv6 networks, but they are generally not possiblewith nodes and hosts that are behind a network address transla-tor (NAT) with respect to a sender as is often the case in IPv4networks. In other words, IPv6 supports end-to-end address-ability while IPv4 networks with NATs based configurationsoften break the end-to-end addressability between a policyserver and policy managed objects.

B. Host Based Security

In an end-to-end security model substantial security burdenis placed on the end hosts. This situation is not unwelcome

because hosts are generally best suited to analyze the securityconsequences of the contents of a packet that they send or re-ceive. The situation however necessitates the deployment ofhost based security (HBS) measures. Because the enterprisesecurity in this model largely depends on the success of thesemeasures strict enforcement of host security configurations

becomes paramount. This strict enforcement is achieved usingthe concepts of the trust zones and the policy based security

management.This section discusses HBS mechanisms and how the HBS

components should integrate. The specification of the trustzones is discussed in section D and their use in policy basedsecurity management is discussed in section E.

Figure 1 shows two hosts communicating with one another,and with the policy server. The solid line in figure 1 represents

the end-to-end connection between the hosts, while the dashedlines represent the policy flows between the policy server andthe network elements, including the host and the host basedsecurity modules. The two hosts can belong to different trustzones (see section D). Therefore different graphics are used infigure 1 for the two hosts and the associated HBS modules. Animplementation may choose to integrate in one appliance boththe host and the associated HBS, but logically they remain dis-tinct entities as is depicted in figure 1.

The security measures in the HBS go far beyond the currentsecurity practices in hosts. It now combines the functionalitiesof the host intrusion detection/prevention as well as the net-work intrusion detection/prevention. These capabilities aredeployed in regular hosts and routers, as well as in dedicatedsecurity manager hosts whose primary function is to apply fil-ters and manage intrusions. Such dedicated hosts are also

placed at the network perimeters, so that perimeter based secu-rity discussed in section C should be considered as part of theHBS measures, in a distributed HBS sense [20].

Some desirable features for HBS are summarized below.

The HBS should provide centralized management ofsecurity and security policy administration, and itshould be automatable where appropriate. These andother functions are performed for HBS by the policy

based security management (PBSM) module shown infigure 1 and discussed in section E.

HBS should have a capability to audit the security pol-icies. This typically means the following: (a) the integ-rity of the policies should not be compromised, (b) thesystem configurations should be flagged when they areat deviance with the currently deployed security poli-cies, (c) a policy validation function should ensure thatthe policies perform the functions that they are in-tended to perform, and (d) it should be possible tocompare the policy performance data with the opera-

tional efficiency data to improve the performance ofthe policy controlled functions. In the current modelthe policy audit function is included as part of thePBSM discussed in section E.

All components for HBS should be interoperableacross the enterprise. For example the components forvirus control, intrusion management, event analyzer,security policy manager, security auditor, data formatsand semantics, and zone level security server should all

be interoperable. This interoperability means that thecomponents will interface correctly, exchange opera-tional data and interpret their semantics correctly, and

provide such data to external systems for security mon-itoring and auditing as required. An example of the lat-

ter is the Einstein intrusion detection/prevention systemthat accepts input from the computer systems of theU.S. Federal agencies and processes the informationfor computer incidence response center (CIRC) [ 21].

The security incidences should be analyzed in at leasttwo ways. First is the local analysis to understand thesecurity of the local operations. Second is the analysisat the zone level to correlate and investigate incidences

503


5/7

from all the relevant hosts within the trust zone. Theresults of the analysis can be fed back to the policyevaluation process [22] to facilitate a feedback loop,and to help with some of the policy auditing functions.

It is desirable that HBS components be based on com-mercial off the shelf systems because the number ofdeployments may be large and commercial systemscost relatively less and their capabilities evolve natu-

rally under market forces. These components should bemanaged from a centralized management system, andmade secure by the use of appropriate security policies.The HBS operations should not impact the perform-ance of the host with respect to the primary tasks thatthe host is intended to perform. Thus the HBS shouldfunction without performance degradation of the pro-tected system.

C. Perimeter Based Security

The use of host based security (HBS) does not disallow theuse of perimeter based security measures. If required, firewallfiltering and intrusion analysis devices can still be used at the

perimeter. Figure 1 explicitly shows the use of perimeter secu-rity devices. They are a distributed part of the HBS. There is,however, one important caveat: the perimeter security devicesin this model do not reassemble the fragmented packets andthey do not decrypt packets that the sending hosts encrypted.

It remains a topic of further research if the use of high as-surance Internet Protocol Encryptor (HAIPE) devices [23] isadmissible because the answer depends on the HAIPE deploy-ment architecture, the application and the mission. There ap-

pears to be no a priori conflict if HAIPE is deployed as usual atthe boundary of the red network and the black core in theglobal information grid (GIG) 2 .

D. Trust Zones

As stated earlier, the use of HBS requires assurance that thesecurity configurations of the hosts will be strictly enforced inaccord with the enterprise security policies. This assurance is

provided via the trust zones, as is discussed below.

A trust zone is defined in terms of the security policies thatapply to the elements in that zone. Each host or network ele-ment belongs to at least one trust zone. When a network ele-ment belongs to more than one trust zones, it is administered byapplying the security policies for all those zones. The zone

policies are applied strictly and uniformly to all hosts, routers,security devices and applications. This is shown by the dottedlines in figure 1 representing the flow of appropriate trust zone

policies to the corresponding network elements. In general,security policies are different for different nodes. Thus the

policies for the two edge routers are different because theyconnect to different set of customers. Similarly the two hosts

belong to two different trust zones and therefore receive differ-ent set of security policies. The two host Based Security sys-tems are controlled by different security policies because they

2 Department of Defense Directive Number 8100.1, September 192002.

are part of different trust zones and they have different configu-rations with respect to the peripherals. The figure does distrib-ute identical policies to the two interior routers assuming theyare identically configured under the same autonomous system.

For host based security to work it is necessary to ensure thata hosts security configuration is accurate and uses the uniformsemantics of the trust zone. It is not enough just to configurethe hosts with correct security configurations, it is even more

important to assure that the enforcement of these configurations be accurate and flawless. The configuration of the hosts andtheir enforcement is implemented using the security policiesthat govern the trust zone to which a host belongs. The security

policies of a trust zone are deployed through the policy man-agement processes. The policy based security management(PBSM) technology [ 24] discussed in section E provides thenecessary enforcement functions for the trust zone security

policies, and the automation of those functions. While the trustzones formally define the security policies that apply to a host,PBSM ensures that the correct policies are used, each policy isinterpreted and evaluated in a consistent way, and each policyis enforced strictly without lapses.

The new security model for the IPv6 infrastructure thus

uses a trust model for the enterprise security which is very dif-ferent from the one used by the current perimeter based secu-rity.

E. Policy Based Security Management

The policy based security management (PBSM) [25] implements the policy functions, automates them, evaluates andexecutes policies, and ensures that the trust zones are enforcedstrictly, uniformly, and flawlessly.

The basic policy based management architecture [25] pro-vides the essential components for PBSM, namely policy ad-ministration, policy decision points (PDP), and policy execu-tion points (PEP). Policy audit [24] should be added to this set

of components.PBSM translates those security policies that define a trust

zone into policy rule-sets that are implementable into a computer language. This implies a translation from the executive policy directives to a set of digital policies that can be interpreted and evaluated by computers. The digital policies aredistributed to the PDPs where they are evaluated to arrive atunique and unambiguous policy actions. The policy actions arestrictly enforced via the PEPs.

PBSM thus implements a trust zone by implementing andenforcing the security policies that specify the trust zone. It alsohelps organize the trust zones within an enterprise. This organi-zation can be hierarchical, in which case PBSM can provide ameans to inherit the digital policies of a higher level trust zoneinto a lower level trust zone. In another context the trust zonesmay be overlapping, in which case PBSM provides a mecha-nism where a common set of security policies applies acrossthe objects belonging to the overlap. In the latter case, the set ofsecurity policies that specify the various trust zones must bemutually consistent and compatible in order to apply their sumto the managed objects belonging to the overlap of the trust

504


6/7

zones. This requires a capability to deconflict the security poli-cies.

Membership in a trust zone defines a clear mechanism toselect the digital policies that apply to a particular networknode. Thus the security policies can be automatically selected,evaluated, and applied to a network node in a given securityoperation.

Some of the above mentioned PBSM architectural featuresare illustrated in figure 2. It shows how a policy server can beused to manage trust zones and use the trust zones to managetheir member objects via an appropriate set of PDPs. Eachmanaged object has its own PEP that is controlled by its PDP.The PDP and PEP can use common open policy services(COPS) protocol specified at the IETF [26 ] and the PolicyServer can use RFCs 2940, 3084, and 3483 respectively to de-fine managed objects [27] under COPS, to provision policies[28], and to use COPS for policy auditing [29].

Figure 2: High level PBSM architecture

Not shown in figure 2 are the PBSM features like the PolicyAuditing and how it helps make the security decisions sensitiveto the operational context [30] and responsive to a changingoperational picture. This agility comes from three mainsources: first, the policy rule-sets can be changed and appliedwithout a need to change the operational software code; sec-ond, the decision logic in the PDPs can be made dependent onthe near-real-term parameters, and; third, different algorithmsto make the security decisions can be selected based on thechanged operational picture.

The number of policy servers and PDPs as well as their physical and logical locations are matters of PBSM design. It isa design choice for an enterprise to decide which policies aredistributed to which PDPs by which PBSM servers. For exam-

ple, an enterprise may deploy a separate PBSM server to dis-tribute policies to a defined conglomerate of trust zones. Figure2 shows a Policy Server that controls three trust zones whichare managed using two PDPs. The more mundane features ofPBSM are the policy definition, policy translation, policy de-confliction, policy distribution, policy evaluation, policy execu-tion, and policy auditing. These are important functions that are

not discussed in this paper because they are already adequatelyaddresses in the literature [31].

F. Other Capabilities

Other security capabilities, including the ones that exist forthe IPv4 networks, remain available for the new security modelfor IPv6 network infrastructure. These capabilities can be usedeven if they are not explicitly discussed here, provided they arenot inconsistent with the use of the components describedabove. Such capabilities can be used to mitigate IPv6 specificvulnerabilities or vulnerabilities that are common to both pro-tocols [2]. Examples of such capabilities include the use ofIPsec, HAIPE, SEND, cryptographically generated addresses(CGA), special purpose addresses, port filtering, firewalling,IDS, IPS, and anomaly analysis.

IV. CONCLUSIONS The changes made in specifying IPv6 protocol relative to

IPv4 have provided powerful new capabilities. However, theyhave also given rise to a set of IPv6 specific security vulner-abilities. These vulnerabilities must be mitigated in order toachieve operational parity with the IPv4 networks. This meansthat the vendors must provide security devices with additionalcapabilities for packet filtering and intrusion management. Inaddition, network engineering is needed for the IPv6 securityarchitecture of an enterprise. The additional cost and engineer-ing effort still achieves only parity with IPv4: it does not re-solve the currently unresolved security issues in IPv4 networkssuch as the support for end-to-end connectivity, encryption, andtunneling; nor does it support capabilities for net-centric opera-tions.

The paper therefore argues that a new security model forIPv6 infrastructure is needed to save cost and to take security

beyond merely achieving parity with IPv4. Such a securitymodel is constructed using six components: the end-to-endaddressability, host based security, perimeter based security,trust zones, policy based security management, and other com-

ponents. All the components of the model are achievable usingtodays technologies, though some of them use emerging tech-nologies like policy based security management. Based on anunderstanding of the component technologies, it is argued thatthe model is flexible, extensible, and scalable to meet the secu-rity requirements of future net-centric operations.

V. ACKNOWLEDGMENTS

TrustZone #1

ZoneSecurityPolicies

ZoneMemberObjects

TrustZone #3

ZoneSecurityPolicies

ZoneMember

Objects

TrustZone #2Zone

SecurityPolicies Zone

Member

Objects

PEP A

Managed Object A

PEPC

Managed Object C

PEPB

Managed Object B

PolicyServer

PDP Zones 2 and 3

PDP Zone 1

Dr. Choudhary thanks Yasmeen Sultana for encourage-ment. Mr. Sekelsky thanks Serco North America for support.

505


7/7

VI. R EFERENCES

[1] Lancaster, Troy, IPv6 and IPv4 Threat Review with Dual StackConsiderations, COMP6009: Individual Research Project, Univer-sity of Southampton, Department of Electronics and Computer Sci-ence, UK, 2006.

[2] Convery, Sean and Miller, Darrin, IPv6 and IPv4 Threat Compari-son and Best Practices Evaluation (v1.0), Cisco Corporation, 2004.

[3] A. Rahim Choudhary, In-Depth Analysis of IPv6 Security Pos-ture, 4 th International Workshop on Trusted Collaboration at 5 th In-ternational Conference on Collaborative Computing, Crystal City,VA, November 2009.

[4] IETF RFC 2460, Internet Protocol, Version 6 (IPv6) Specifica-tion, December 1998.

[5] IETF RFC 791, Internet Protocol, DARPA Internet Program,Protocol Specification, September 1981.

[6] IETF RFC 4301, Security Architecture for the Internet Protocol,December 2005.

[7] IETF RFC 4862, IPv6 Stateless Address Autoconfiguration,September 2007.

[8] IETF RFC 3756, IPv6 Neighbor Discovery (ND) Trust Modelsand Threats, May 2004.

[9] IETF RFC 4861, Neighbor Discovery for IP version 6 (IPv6),

September 2007.[10] IETF RFC 4890, Recommendations for Filtering ICMPv6 Mes-

sages in Firewalls, May 2007.

[11] IETF RFC 3971, Secure Neighbor Discovery (SEND), March2005.

[12] IETF Internet Draft draft-nward-ipv6-autoconfig-filtering-ethernet-00, March 4, 2009.

[13] Orla McGann, IPv6 Packet Filtering, a Masters Thesis at De- partment of Electrical Engineering, National University of IrelandMaynooth, Supervised by David Malone, January 2005.

[14] IETF RFC 3056, Connection of IPv6 Domains via IPv4 Clouds,February 2001.

[15] IETF RFC 3964, Security Considerations for 6to4, December2004.

[16] IETF Internet Draft draft-vives-v6ops-ipv6-security-ps-03.txt,February 2005.

[17] A. Rahim Choudhary, Network Management Requirements for Net-Centric Systems, Military Communications (MILCOM), SanDiego, CA, November 2008.

[18] National Institute of Standards and Techmology/National Tele-communications and Information Administration, Technical andEconomic Assessment of Internet Protocol version 6 (IPv6), IPv6Task Force, January 2006.

[19] IETF RFC 2775, Internet Transparency, February 2000.

[20] S. Loannidis, A. Keromytis, S. Bellovin, J. Smith, Implementinga Distributed Firewall, Proceedings of the 7 th ACM Conference onComputers and Communications Security, Athens, Greece, 2000.

[21] Hugo Teufel III, Department of Homeland Security, Privacy Im- pact Assessment for Einstein 2, May 19, 2008.

[22] O. Patrick Kreidl and Tiffany M. Frazier, Feedback control applied to survivability: A host-based automatic defense system,IEEE Transactions on Reliability, vol. 53, p. 148 166, 2004.

[23] G. Nakamoto, Scalable HAIPE Discovery, proceedings of Visu-alizing Network Information, NATO RTO-MP-IST-063, Neuilly-sur-Seine, France, 2006.

[24] A. Rahim Choudhary, Policy based management in the GlobalInformation Grid, Int. J. Internet Protocol Technology vol. 3, p. 73

80, 2008.

[25] A. Rahim Choudhary, Policy Based Network Management, BellLabs Technical Journal Vol. 9, pp. 19-29, 2004.

[26] IETF RFC 4261, Common Open Policy Service (COPS) OverTransport Layer Security (TLS), December 2005.

[27] IETF RFC 2949, Definitions of Managed Objects for CommonOpen Policy Service (COPS) Protocol Clients, October 2000.

[28] IETF RFC 3084, COPS Usage for Policy Provisioning (COPS-PR), March 2001.

[29] IETF RFC 3483, Framework for Policy Usage Feedback forCommon Open Policy Service with Policy Provisioning (COPS-PR) , March 2003.

[30] A. Rahim Choudhary and J. O. Odubiyi, Context Based AdaptiveControl in Autonom ous Systems, Proceedings of IEEE Informa-tion Assurance Workshop, US Military Academy, West Point, NY,June 2004.

[31] J. Strassner, Policy Based Network Management: Solutions for the

Next Generation, The Morgan Kauffman Series in Networking,ISBN 1-55860-859-1, Elsevier, 2003.

506

securing ipv6.pdf

Documents