Network Working Group                                         M. Bagnulo
Internet-Draft                                                      UC3M
Intended status: Informational                          October 20, 2006
Expires: April 23, 2007


                Privacy Analysis for the SHIM6 protocol
                     draft-bagnulo-shim6-privacy-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 23, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This note presents a privacy analysis for the SHIM6 protocol for IPv6
   site multihoming support and the failure detection extensions for the
   SHIM6 protocol.This note does not attempt to provide a solution for
   providing SHIM6 protocol privacy.







Bagnulo                  Expires April 23, 2007                 [Page 1]


Internet-Draft           SHIM6 Privacy Analysis             October 2006


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Privacy of the ULID-pair context establishment exchange . . . . 3
   3.  Payload packets . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Other Signalling messages . . . . . . . . . . . . . . . . . . . 6
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9








































Bagnulo                  Expires April 23, 2007                 [Page 2]


Internet-Draft           SHIM6 Privacy Analysis             October 2006


1.  Introduction

   This note presents a privacy analysis for the SHIM6 protocol as
   defined in [1] and the failure detection extensions for the SHIM6
   protocol defined in [2].

   The scenario considered is the following: two nodes are communicating
   using the SHIM6 protocol to achieve enhanced fault tolerance
   capabilities.  The potential attackers are located along the path and
   their goal is to obtain relevant information by observing the
   exchanged packets.  In particular, we consider that information
   harvesters may be interested in determining whether a set of
   addresses belongs to a single host or if a set of packets exchanged
   using different address pairs belong to the same communication.  In
   the following sections we will analyze the information contained in
   the SHIM6 protocol messages that can be used to obtain such
   information.

   It should be noted that this analysis is limited to malicious third
   parties that are located along one or several of the available paths
   between the communication parties and that it is out of the scope of
   the analysis the case where the potential attacker is one of the
   parties involved in the communication i.e. the goal is not to avoid
   the disclosure of locator information from the peer.

   The remaining of this note is structured as follows: in the next
   section we will perform a privacy analysis of the SHIM6 4-way
   exchange to establish ULID-pair contexts.  Next, we will analyze the
   privacy aspects of the payload packet exchange and finally we
   consider the privacy implications of other protocol messages,
   including the failure detection protocol for the SHIM6 protocol.


2.  Privacy of the ULID-pair context establishment exchange

   The ULID-pair context establishment exchange consists of 4 messages:
   I1, R1, I2 and R2.  We will next analyze the privacy implications of
   each of them.

   The I1 message is exchanged using a valid locator pair in the IPv6
   address fields.  In addition, the I1 message contains the Initiator
   context tag and nonce.  Besides it can carry additional options.  In
   particular, in case that the locator pair used differs from the ULID
   pair for the context, an ULID-pair option must be carried in the I1
   message.

   Among the information carried in the I1 message we consider that the
   following may have privacy implications if it can be observed by a



Bagnulo                  Expires April 23, 2007                 [Page 3]


Internet-Draft           SHIM6 Privacy Analysis             October 2006


   third party:
   o  The binding between a locator pair and ULID pair if the ULID-pair
      option is carried in clear text
   o  The Context Tag information can be used by an attacker in order to
      correlate different packets containing different locator pairs.
      Through this mean, the attacker can learn that multiple locators
      belong to the same endpoint and that the different packets
      carrying different address pairs belong to the same communication.

   In order to achieve privacy protection, it is required to conceal all
   this information.

   The next message to be exchanged is R1.  This message contains a pair
   of valid locators in the IPv6 address fields and in the message
   itself, it contains the Initiator nonce and the Responder nonce.  In
   addition, the R1 message support the Validator option, which contain
   cryptographic information.

   The disclosure of any of these elements doesn't seems to raise any
   privacy concerns, so there does not seem to be any requirement to
   conceal the information carried in the R1 message.

   After the R1 message the ULID-pair context establishment continues
   with the I2 message.  The I2 message is carried in a packet
   containing again a valid locator pair in the IPv6 header address
   fields and, in the I2 message itself the Initiator context tag, the
   Initiator and Responder nonces are conveyed.  The I2 message can
   carry also the following options: ULID pair, Forked Instance
   Identifier, Locator list, Locator Preferences, CGA Parameter Data
   Structure and CGA Signature.

   Of all the aforementioned information conveyed in the I2 message, we
   identify the following items that may imply privacy concerns:
   o  The Initiator Context tag, for the same reasons than in the I1
      message
   o  The ULID-pair option, for the same reasons than in the I1 message
   o  The locator list option, since it carries the list of locator
      which disclosure would clearly result in allowing the attacker to
      identify the multiple locator associated with a single endpoint
   o  The CGA parameter data structure option.  In this case, it depends
      of which information is carried in the data structure.  If a
      multiprefix extension is carried i.e.  HBA are used, then the
      information is critical from a privacy perspective, since the
      information about multiple prefixes and hence about multiple
      locators is included in the data structure.  If the multiprefix
      extension is not included, then the CGA parameter data structure
      could be used by an attacker to obtain identifier information
      (since there is enough information in the data structure to re-



Bagnulo                  Expires April 23, 2007                 [Page 4]


Internet-Draft           SHIM6 Privacy Analysis             October 2006


      create the associated CGA).  So if the CGA is being used as
      locator in the packet (and no multiprefix extension is being
      used), then the CGA parameter data structure is not critical from
      a privacy perspective.

   The other information carried in the I2 message is not considered to
   be critical for preserving the privacy.  In particular, the Forked
   Instance Identifier could be used to correlate different packets, but
   without knowing the Context tag, the attack seems not very practical.
   The Locator preference option may inform about the number of locators
   available and the relative preference between them, but without
   knowing the actual locators, this information does not seem to be
   very relevant neither.  Finally, the CGA signature information does
   not seem to provide any useful information for an attacker.

   The last packet of the initial exchange is the R2 packet that
   contains the Responder context tag, and the following potential
   options: Locator List, Locator Preferences, CGA Parameter Data
   Structure, CGA Signature.  Analogously to the I2 case, the following
   information needs to be concealed: the Responder context tag, the
   Locator list option, the CGA Parameter Data structure.

   In addition to the four messages of the basic ULID-pair context
   establishment exchange, there are also two additional messages
   defined, that need to be analyzed also these are the R1bis packet and
   the I2bis packet.

   The R1bis message is carried in a packet that carries valid locators
   in the IPv6 address fields and the message itself contains the Packet
   context tag and the Responder nonce.  In addition, it also can carry
   the Validator option.

   Similarly to the R1 packet, the R1bis packet does not carries any
   critical information from a privacy point of view.

   The I2bis message is also carried in a packet that contains valid
   locators in the IPv6 address fields and it carries the following
   information in the message: Initiator context tag, the Initiator and
   Responder nonces and the Packet context tag.  In addition it allows
   the following options: Responder Validator, ULID pair, Forked
   Instance Identifier, Locator list, Locator Preferences, CGA Parameter
   Data Structure and the CGA Signature.

   Similarly to the previous cases, the following information needs to
   be concealed in order to preserve privacy: Initiator context Tag,
   ULID pair option, Locator List option, CGA Parameter Data Structure.





Bagnulo                  Expires April 23, 2007                 [Page 5]


Internet-Draft           SHIM6 Privacy Analysis             October 2006


3.  Payload packets

   Payload packets are data packets that carry the SHIM6 header
   containing the Payload option.  This option carries the Receiver
   context tag.  The main privacy issue related to the Payload packets
   is that they may change the locator pair used while keeping the
   Context tag unchanged.  The problem with this approach is that an
   attacker located along the different paths can correlate different
   packets carrying different locator pairs through the constant context
   tag included in the payload header.  Through this mean, the attacker
   can determine different locators of the locator set and determine
   that different packets exchanged belong to a single communication.
   In order to prevent this privacy breach, it is required that
   different unrelated context tags are used when the locator pair is
   changed.


4.  Other Signalling messages

   In addition to the messages previously analyzed, the SHIM6 protocol
   also defines the Update Request and Ack messages and the Keepalive
   and Probe messages.  We will next perform the privacy analysis for
   these messages.

   The Update Request carries the Context tag and the request nonce and
   it supports the following options: Locator List, Locator Preferences,
   CGA Parameter Data Structure, CGA Signature.

   As for the prior analysis, the critical information from a privacy
   perspective is the following: the context tag (if a different locator
   pair is being used), the Locator List option, and the CGA parameter
   data structure (with the considerations described above).

   The Update Ack message contains the context tag and the request
   nonce.  If different locator pair is used, the context tag and the
   request nonce can be used to correlate different packets with
   different locator pairs.  In this case, the context tag and nonce
   information need to be concealed to protect privacy.

   With respect to Keepalive and Probe messages, the critical
   information contained in those messages is the following: the context
   tag and the identifier information carried in different options
   available.

   The considerations with respect to the context tag information are
   similar to the ones already discussed for other messages.

   With respect to the Identifier information, this information would



Bagnulo                  Expires April 23, 2007                 [Page 6]


Internet-Draft           SHIM6 Privacy Analysis             October 2006


   allow the correlation of different Keepalive and Probe packets,
   allowing then to bind different locators used in different packets.
   In order to preserve privacy, the Identifier information need to be
   concealed.


5.  Conclusion

   It is clear that there is quite a few information included in the
   SHIM6 protocol that need to be concealed in order to provide privacy
   support for the SHIM6 protocol.  However, it is likely that
   encrypting the critical information using a shared secret generated
   through a Diffie Hellman exchange would provide enough protection for
   most of the cases.  There are however two cases that would require
   additional study: one is the case of the information exchanged in the
   I1 packet, which is the first message to be exchanged implying that
   no previous shared secret can possible be exchanged.  In order to
   address this case, or additional prior message exchange is included
   in the protocol to provide privacy or the critical information is
   removed from the I1 message.  Another case that would require further
   analysis is the case of the context tag.  The context tag is used to
   demultiplex incoming packet.  In order for this to be useful, the
   context tag needs to be known beforehand by both ends and in order to
   provide privacy support, the context tag needs to be changed when the
   locator pair is changed.  Mechanisms for changing the context tag
   depending on the locator pair used can be defined, keeping in mind
   that the relation between the locator pair and the context tag must
   remain untraceable for an external observer.


6.  Security considerations

   This note analyzes the privacy issues of the SHIM6 protocol.
   Additional security considerations of the SHIM6 protocol are
   addressed in the protocol specification itself


7.  References

   [1]  Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach",
        draft-ietf-shim6-l3shim-00 (work in progress), July 2005.

   [2]  Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
        Exploration Protocol for IPv6  Multihoming",
        draft-ietf-shim6-failure-detection-03 (work in progress),
        December 2005.





Bagnulo                  Expires April 23, 2007                 [Page 7]


Internet-Draft           SHIM6 Privacy Analysis             October 2006


Author's Address

   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911
   SPAIN

   Phone: 34 91 6249500
   Email: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es








































Bagnulo                  Expires April 23, 2007                 [Page 8]


Internet-Draft           SHIM6 Privacy Analysis             October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Bagnulo                  Expires April 23, 2007                 [Page 9]