[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                              J. Bi
Internet-Draft                                                     J. Wu
Intended status: Experimental                                     G. Yao
Expires: January 28, 2009                                         CERNET
                                                           July 27, 2008


   A CGA based Source Address Authorization and Authentication (CSA)
                  Mechanism for First IPv6 Layer-3 Hop
                        draft-bi-savi-csa-00.txt

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 January 28, 2009.
















Bi, et al.              Expires January 28, 2009                [Page 1]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


Abstract

   This document describes a method to authorize and authenticate the
   address of a node in an IPv6 network.  Except for "Host Change", this
   method satisfies all the requirements in the Charter of SAVI.  The
   modification on a host can be regarded as the extension of SEND and
   IPSec.


Table of Contents

   1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3

   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  Address Authorization  . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Address Preparation  . . . . . . . . . . . . . . . . . . .  5
     3.2.  Identifier Generation  . . . . . . . . . . . . . . . . . .  7
     3.3.  Address Request  . . . . . . . . . . . . . . . . . . . . .  8
     3.4.  Gateway Authorizing Address  . . . . . . . . . . . . . . . 10
     3.5.  Address Assignment . . . . . . . . . . . . . . . . . . . . 13

   4.  Address Authentication . . . . . . . . . . . . . . . . . . . . 14
     4.1.  Signature Generation . . . . . . . . . . . . . . . . . . . 14
     4.2.  Signature Addition . . . . . . . . . . . . . . . . . . . . 14
     4.3.  Sending packet . . . . . . . . . . . . . . . . . . . . . . 15
     4.4.  Packet Checking by the Router  . . . . . . . . . . . . . . 15
     4.5.  Router Transmitting Packet . . . . . . . . . . . . . . . . 15

   5.  Some Consideration . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  Refresh of the mapping table . . . . . . . . . . . . . . . 16
     5.2.  Cooperating with SEND  . . . . . . . . . . . . . . . . . . 16
     5.3.  Deployment not on first-hop router . . . . . . . . . . . . 16
     5.4.  Spoofing Prevention Functionality  . . . . . . . . . . . . 16
     5.5.  Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 17
     5.6.  Other Considerations . . . . . . . . . . . . . . . . . . . 17

   6.  Comparision with Charter . . . . . . . . . . . . . . . . . . . 18

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23






Bi, et al.              Expires January 28, 2009                [Page 2]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].














































Bi, et al.              Expires January 28, 2009                [Page 3]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


2.  Introduction

   In this method, a node must request the right to use an IPv6 address
   from the first-hop gateway(either a layer 2 gateway or a layer 3
   gateway).  The first-hop gateway makes a decision on whether the
   address can be used by the node, according to the current address
   allocation method.  Following an affirmative decision, a secret is
   exchanged between the node and the gateway.  Whenever the node wants
   to send a packet via the gateway, a signature MUST be added into the
   packet if required by the gateway.  The signature is generated using
   the shared secret and both the gateway and the node know the
   generating algorithm.  The gateway checks the signature to confirm
   that the packet is from the owner of the source address.  An
   identifier called "CGA identifier" is used to help in the address
   ownership determination.

   When a host is connected to a monopolized port of a switch, the
   switch can enable filtering at the port to prevent spoofing packets
   from the host easily.  However, it may comes that there is no switch
   between the host and the router, or more than one hosts share a port
   through a hub, or not all the switches in the network can be updated/
   replaced to enable filtering.  This method is designed to suit in the
   situation where it is not possible to perform filtering on the port
   of switch.  Though it is relatively more complex and the overhead is
   higher, this method has good flexibility since it is independent of
   the interconnection medium.  And generally it is more economical
   since it doesn't require replacing all the switches in a network.

   This mechanism comprises of two main parts: The address authorization
   process and the address authentication process.





















Bi, et al.              Expires January 28, 2009                [Page 4]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


3.  Address Authorization

   This process is shown in the Fig.1.


                   Node               Gateway
               |                 |
               |  Request Addr A |
    Address    |---------------->|
    Request    |  Identifier=IA  |
               |  Pub Key=Pk     |
               |                 |
               |                 |
               |                 |Address Use Right Check,
               |                 |Binding(IA,Pk,A,Seed)
               |                 |
    Address    |  Comfirm Addr A |
   Assignment  |<----------------|
               |  Signature Seed |
               |  Encypted by Pk |
               |                 |


                  Figure 1: Address authorization process

3.1.  Address Preparation

   We emphasize the manner of address assignement since we define IP
   spoofing to be taking place when a user/host/interface uses one or
   more addresses which are not assigned to it by the appointed
   allocation method, or the configuration of an allocated address is
   incorrect.  IP spoofing caused by erroneous configuration is
   generally not malicious and can be corrected easily once the error is
   detected.  Moreover, if the allocation mechanism is misconfigured,
   the spoof filtering mechanism has no way to run correctly since the
   information used in filtering will also be incorrect.  Thus we only
   deal with the use of addresses not allocated to the user/host/
   interface by the allocation method.

   In this stage, if the node is a host, it MUST prepare an address.
   The address MUST be got according to current address allocation
   method.  In IPv6, this means:

   Manually: the address MUST be got from the network administrator.
   This means the address is allocated to the host/user/interface by the
   administrator.

   DHCP(either stateless or stateful): the address MUST be got from the



Bi, et al.              Expires January 28, 2009                [Page 5]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


   DHCP server[DHCP,stateful,stateless].  To help affirm which host gets
   the ownership of the address returned by the DHCP server, the request
   message must be changed to contain an unspoofable host identifier.
   We chose CGA[CGA] to play the role of the identifier in preference to
   PKI.  The procedure of DHCP allocation is changed as follows: The
   node MUST use a CGA address as the source address to request an
   address from the DHCP server.  The CGA address MUST be generated
   using the procedure described in [CGA].  The corresponding CGA option
   and signature MUST be contained in the packet.  The request packet
   MUST contain a random nonce to prevent replay attack.  The first-hop
   layer-3 gateway MUST have the ability of obtaining the request
   message and the response message of the DHCP server.  The DHCP server
   MAY be placed outside of the local network and so the gateway will
   forward both kinds of message.  Alternatively, these packets MAY be
   changed to multicast packets to reach the gateway, or yet other
   methods may be chosen here.  The gateway MUST check the correctness
   of signature and address portion of the request packet, and discard
   invalid packets.  The gateway MUST record the CGA address in the
   validated request packet, and wait for the response packet from the
   DHCP server.  Once a response message arrives, the gateway will check
   which address is allocated to the applicant and bind the CGA address
   of the applicant to the allocated address.  The advertised address in
   the response packet is the address allocated to the host.  If there
   is any DHCP relay point, the source address of the request packet
   MUST be unchanged before it reaches the gateway.

   Stateless Autoconfiguration: the address MUST be got using NDP and
   there MUST be no duplication[SAC].

   Privacy: the address MUST be got using NDP and there MUST be no
   duplication[Privacy].  This mechanism doesn't guarantee the privacy
   requirement of node.  The node MUST use its own policy to achieve
   privacy.  [Privacy].

   CGA: the address MUST be generated according to CGA generation
   algorithm[CGA].  The Sec value is decided according to the
   requirement of administrator.

   An arbitrarily generated address will not be regarded as an illegal
   address unless it is forbidden under the rules of the appointed
   address allocation method.  For example, in the manual configuration
   case, if a node uses any address other than its allocated address, it
   is spoofing.  However, if in the SAC situation, a host can use other
   addresses as long as they are not being used by other hosts, even if
   no DAD has been performed.

   The address preparation stage MAY be combined with the other stages
   to simplify the procedure.  For example, the DHCP address MAY be



Bi, et al.              Expires January 28, 2009                [Page 6]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


   obtained together with the signature seed described in the next
   section.

   If the node is a NAT gateway, it will prepare one or more addresses.
   In all cases, the addresses will be allocated by administrator
   manually.

   If the node is a DHCP-PD router, it prepares one or more prefixes
   instead of one address.  The prefixes are obtained using the DHCP-PD
   protocol.  In all cases these prefixes will be previously configured
   by the administrator.

   If the node is an IPv4 node, the only different case is DHCP.  The
   node cannot use a CGA address to send a DHCP solicitation.  This can
   be solved by using the address as an identifier, but not as a
   locator.  The CGA address in contained in the packet as an option,
   and the host id of the IPv4 address is the hash of the CGA address.
   The signature is computed on the whole packet.

   Other than for DHCP, there is nothing different from normal address
   allocation method in this stage.  In manual allocation, we already
   know which address has been allocated to whom.  Thus the validation
   of the ownership of the address must be based on some existing and
   fixed knowledge, but not a stateless CGA identifier.  In SAC and
   similar mechanisms, since there is actually no "allocation"
   procedure, a node can get ownership of any address not being used.
   We don't care who is using the address.  In some case we do care who
   is using an address, but this problem is actually out of the scope of
   preventing IP spoofing.  The solution of tracing the user of an
   address requires modification of the SAC protocol.

3.2.  Identifier Generation

   After preparing an address, a node must request the right to use the
   address from the first-hop layer-3 gateway.  It tells the gateway
   "who I am, and which address I want to use".  So there must be a
   field in the request packet to show the identity of the applicant,
   and the value of the field must be unspoofable.  Again we choose CGA
   to help generate an identifier of the applicant.  In DHCP and SAC
   cases, CGA works well.  However, in the manual configuration case,
   the identifier must be stateful and contain fixed information about
   the applicant, because the applicant must tell the gateway that it is
   the very person/host that owns the address, but not some random
   person/host.  In this case stateless CGA generation is not
   appropriate.  We choose using a shared secret to authenticate the
   identity of a node in all manual configuration cases.  This means if
   one knows a correct shared secret, it will get ownership of the
   corresponding address.  Thus the shared secret must be protected in



Bi, et al.              Expires January 28, 2009                [Page 7]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


   the message exchchange and replay attack must be avoided.  Adding
   state into CGA generation is one possible way of solving this
   problem.  For example, the shared secret between the applicant and
   the gateway could be combined with the public key and a random nonce
   to generate an address.  Then the shared secret would not be leaked,
   and the gateway can recompute the address to ascertain the
   correctness of the secret.

   Using CGA as an identifer actually wastes the left-most 64 bits.
   However, the form of a CGA address is kept and it can be used for
   other purposes.  For example, this mechanism can cooperate with the
   SEND protocol using the CGA identifier.

   The procedure of identifier generation is described as follows:

   The node MUST generate an identifier.  The identifier is a CGA
   address whose left-most 64 bits is the network prefix and the right-
   most 64 bits is generated according to [CGA] except for any address
   allocation method using manual configuration.

   In the case where the address is configured manually, a shared secret
   MUST be previously allocated between the node and the gateway.  The
   shared secret is a bit-string longer than 256 bits(this number is to
   be decided in the future).  The node MUST generate a random number of
   128 bits as a nonce.  Then the right-most 64 bits of the identifier
   is computed by combining the public key, the shared secret, the nonce
   and auxiliary parameters.  The shared secret MUST be allocated
   manually, but not using any key exchange protocol, since the source
   address of the applicant has not yet been authorized.

   If a node wants to use another address, it CAN use another public key
   and identifier or an existing identifer.

   The security of the identifier MUST be guaranteed by the node itself,
   which means the public key pair MUST not be leaked.  IP spoofing
   caused by a deliberate leak will not be stopped by this mechanism.

   There MUST be no public key duplication in the same network.  The
   uniqueness will be checked by the gateway.  Once a duplicate public
   key is found to generate an identifier, the gateway will return an
   error and ask the applicant to use another public key.

3.3.  Address Request

   After preparing the address and the identifier, a node MUST send a
   request packet to the gateway.  This packet is an ICMP packet, named
   Seed Solicitation.  Its format is shown in Fig.2.




Bi, et al.              Expires January 28, 2009                [Page 8]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Code      |          Checksum             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Address Allocation Method  |       Prefix Length           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                           Nonce                               |
        +                                                               +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                                                               |
        +                       CGA Identifier                          +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                                                               .
        .                         CGA Option                            .
        .                                                               .
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                                                               .
        .                      RSA Signature Option                     .
        .                                                               .
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           Figure 2: The format of the Seed Solicitation message

   IP Fields:

   Source Address: The address prepared in the first stage.

   Destination Address: This portion MUST be filled with the IP address
   of the first-hop layer-3 gateway.

   Hop Limit: 1 or more.  Generally 1 is enough, but there may be some
   extension in the future.  For example, the gateway is not one hop



Bi, et al.              Expires January 28, 2009                [Page 9]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


   away from the node, but several hops.

   ICMP Fields:

   Type: TBD

   Code: TBD

   Checksum: The ICMP checksum.

   Address Allocation Method:

   Index of address allocation method, which shows by which method the
   applicant gets the address.  Now: 1: Manually 2: DHCP 3: SAC 4: CGA
   5: NAT 6: DHCP-PD

   Prefix Length: Only used in DHCP-PD case.  It helps to get the
   request prefix.

   Nonce: A random number that is used to prevent replay attacks.

   CGA Identifier: The identifier generated in the phase of "Identifier
   Generation".

   Options:

   CGA Option: Described in [SeND].

   RSA Signature Option: Described in [SeND].  Used to anthenticate the
   whole message.

   The destination address in the packet is obtained through the RA
   message from the router.  If the RA message is forged by some other
   node deliberately, the node will be deceived.  This may cause
   information leak and the node may be unable to send packets.  Hence
   the security of NDP SHOULD be protected.  However, even SeND cannot
   ensure that the sender of a RA message is actually a router.
   However, we think the first-hop gateway has enough information to
   know the address of the first-hop router, and it SHOULD filter forged
   RA message and prevent forged RA message from reaching any node on
   local link.

3.4.  Gateway Authorizing Address

   In this phase, the gateway checks whether the applicant has the right
   to use the requested address.  This validation is based on the
   knowledge of address allocation.  If the address is able to be used
   by the applicant, a bit string named "signature seed" will be



Bi, et al.              Expires January 28, 2009               [Page 10]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


   returned to he applicant.

   Whenever the gateway receives a SS packet, firstly it performs
   following checks:

   o  Check if the CGA identifier of the packet is a valid CGA
      identifier corresponding to the CGA option.  If not, discard it.
      If the address allocation method is manually configuration, the
      gateway obtains the shared secret of the request address, and
      recomputes the identifier to check whether it is correct.

   o  Check if the signature in RSA signature option is correct.  If
      not, discard it.

   o  Check if either the public key or the CGA identifier duplicates
      any already registered public key or CGA identifier.  If only the
      public key is duplicate, return an ICMP message to ask the
      applicant to generate another key pair.  If both are duplicate,
      check if the nonce is different from the previous entry.  If yes,
      discard the packet; if no, this may happen for a multi-homing
      node, or a node requesting a former address.  This situation will
      be discussed later.

   Then the gateway will check whether the applicant has the right to
   use the requested address.  Depending on the address allocation
   method, the gateway will check different things.

   o  Manual allocation: Once the packet passes the former check on the
      CGA identifier, the shared secret has already been validated.  So
      no further check is required here.

   o  DHCP: The address MUST be the one that the DHCP server has
      allocated to the applicant owning the same CGA identifier in the
      packet.  This means the gateway has to perform DHCP snooping to
      know the association of address and identifier.  This knowledge
      has been in the first phase.

   o  Stateless Auto Configuration: The address MUST not have been
      registered in the gateway.  This means no one has the right to use
      this address yet.

   o  Privacy: The address MUST have not been registered in the gateway.

   o  CGA: The address MUST be unique and generated following the
      algorithm in [CGA].  If there are other restrictions on generating
      a CGA, e.g. the Sec value, they MUST be satisfied.

   Once the address is found to be able to be used by the applicant, the



Bi, et al.              Expires January 28, 2009               [Page 11]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


   gateway will generate a random number called "signature seed".  It is
   a bit string of 384 bits and MUST not be the same as any former
   signature seed.  Then the gateway SHOULD keep an entry in a record
   table, which has following elements: Address, signature seed, CGA
   identifier, public key, Sec value, nonce.  The "signature seed" is
   used to perform a lightweight authentication in the future.

   Then, a packet will be returned to the applicant.  This packet is
   called Seed Advertisement(SA) message, and has following format.



         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Code      |          Checksum             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                                                               |
        .                                                               .
        .                       Signature Seed                          .
        .                                                               .
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                                                               |
        +                       CGA Identifier                          +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                                                               .
        .                         CGA Option                            .
        .                                                               .
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                                                               .
        .                      RSA Signature Option                     .
        .                                                               .
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3: The format of Seed Advertisement message




Bi, et al.              Expires January 28, 2009               [Page 12]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


   IP Fields:

   Source Address: The address of the router.

   Destination Address: The address requested by the node.

   Hop Limit: 1 or more.

   ICMP Fields:

   Type: TBD

   Code: TBD

   Checksum: The ICMP checksum.

   Signature Seed: The signature seed generated by the gateway.  This
   seed MUST be encrypted by the public key of the request node.

   CGA identifier: The CGA identifier of the gateway.

   Options:

   CGA Option: Described in [SeND].

   RSA Signature Option: Described in [SeND].  Used to anthenticate the
   message.

3.5.  Address Assignment

   A node MUST receive any Seed Advertisement packet whose destination
   is the address which it has requested, though the address is not
   being used by the node.

   When a node receives a Seed Advertisement message, firstly it checks
   whether the CGA identifier and the RSA signature are correct.  If
   either of them is incorrect, discard the packet.  Once the node gets
   a valid Seed Advertisement message from the gateway, it can use the
   request address.

   Then the node decrypts the signature seed field to get the signature
   seed, using its private key generated in the phase of "identifier
   generation".








Bi, et al.              Expires January 28, 2009               [Page 13]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


4.  Address Authentication

   In the previous stage, a node obtains authorization to use an address
   and a shared secret "signature seed" has been exchanged between the
   gateway and the node.  Then normal packet communication will start.
   To authenticate normal packets, a signature must be added into the
   packets, and the gateway checks the signature.

   After the node gets the signature seed for the requested address, all
   the a signature MUST be added to all transmitted and this signature
   MUST be checked by the gateway.

4.1.  Signature Generation

   The host generates signatures from the signature seed to sign
   packets.  Here we propose three candidate method to generate a
   signature.

   o  HMAC

   o  Pseudo Random Number Generation

   HMAC is a mature algorithm and has been tested in many authentication
   mechanisms, such as IPSec.  HMAC is robust since it is stateless, but
   it is computed across the entirety of each packet, which will limit
   the forwarding performance of the router.

   Though there have been some commercial products which use Pseudo-
   Random Number Generation to generate one-time keys, the dependability
   of this algorithm used in packet authentication must be tested
   generally.  Since it is stateful, it it is impacted by out-of-order
   packets and dropped packets.  But in perfect network condition, it is
   more effective than HMAC as it isn!_t computed on the contents of
   packets and the signatures can be generated in advance.

   Other signature generation methods can also be used here.  The only
   requirement is that the signature must change with each packet, to
   prevent sniffer and replay attack.

   NAT and DHCP-PD routers MUST generate a signature for any packets
   they transmit.

4.2.  Signature Addition

   The signature can be added into the packet in three ways:

   1 IPSec Authentication Header: It is mature but may conflict with an
   existing AH.



Bi, et al.              Expires January 28, 2009               [Page 14]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


   2 A new option header: The signature is added as a new destination
   option header, or a new hop-by-hop option header.  We have done
   similar work when implementing a prototype of SPM.

   3 Address Rewrite: This is a new method that we have proposed
   recently and its value is still untested.  In this method, the
   signature is not added into the packet as an IP extension header, but
   used to mark the source IP address field.  We proposed this method
   because we found that the overhead of signature addition and removal
   is the bottleneck of the authentication method.  These two operations
   require memory copy which is computationally expensive.  Moreover,
   the location of the signature iscostly because the IPv6 header is
   chaining- structured.  Changing some fixed bits costs less.  Because
   any field of an IP header has a defined meaning, the safest way is to
   change the source address, since it is only used when the receiver
   wants to reply.  The gateway can set up an inverse index table which
   maps signature to address, and if the signature contained in source
   address field is exists in the table, it rewrites the source address
   into the packet.  The rationality of this method is based on a
   spatial and dynamic signature space.

   NAT and DHCP-PD router MUST add the signature for any packets they
   transmit.

4.3.  Sending packet

   After inserting the signature extension header, the node sends it out
   via the link between the gateway and itself.

4.4.  Packet Checking by the Router

   Whenever the router gets a packet, it will check whether the source
   address has been applied for and whether the signature is correct.
   Because the router keeps a mapping table from the address to the
   seed, it is easy to verify the signature.

4.5.  Router Transmitting Packet

   If the signature in the packet is found to be correct, the router
   will remove the Access Network Authentication Header from the packet
   and then transmit it.  If the signature is inserted by rewriting the
   source address, it will replace the signature with the corresponding
   address.








Bi, et al.              Expires January 28, 2009               [Page 15]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


5.  Some Consideration

5.1.  Refresh of the mapping table

   The mapping table of address and signature-seed should be refreshed
   periodically to prevent brute-force attack.  The router should
   periodically send a notification to the host to ask them to update
   the signature-seed and generate new signatures.  Older signature can
   pass the validation for a short period, after which only the new
   signature is accepted.  In APPA, refresh is not needed, because no
   brute-force attack can be effective, and also it is hard to keep
   synchronization of the signature if the signature-seed changes.

5.2.  Cooperating with SEND

   SEND is of great importance to maintain a trust between the host and
   the router.  Without SEND, the host and the router could be deceived
   at the very beginning of the process and all the ensuing steps would
   not be insecure.  Moreover, the seed exchange process can be designed
   as an extension of SEND.

5.3.  Deployment not on first-hop router

   It happens that some first-hop routers can not be upgraded to perform
   this validation.  This mechanism can also be deployed on a distant
   gateway.  The host should know the address of the gateway first, and
   then use the same method to get a signature-seed from the gateway.

   The basic mechanism is much the same.  However, some details need to
   be thought through here.  For example, the snooping of DHCP messages
   may not be possible on a distant gateway may be not possible, and the
   gateway must communicate with the DHCP server.

5.4.  Spoofing Prevention Functionality

   The basic functionality of the method described is that an attacker
   can not use any address that has been successfully applied for by
   others.  This address can be allocated by any method.

   This mechanism cannot prevent a host from using a lot of "reasonable"
   addresses, Because this behaviour does not differ much from normal
   behaviour.  But we can limit the frequency with which a single link-
   layer address can be associated with applications to reserve an
   address.

   This method does not address or support the traceing of ahost using a
   known source address.  Other mechanisms may be added to enhance the
   traceability.  For example a log of link layer address of the Seed



Bi, et al.              Expires January 28, 2009               [Page 16]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


   Solicitation message could be kept in router.  Since link layer
   address can also be forged, we have yet to design a totally effective
   mechanism.

5.5.  Keep-alive

   The router MUST send keep-alive message to ensure that the address is
   still in use.  If the address is not used by any host, the entry in
   the mapping table will be cleared.  This message can be authenticated
   by using the seed already exchanged.  Details will be designed in a
   future document.

5.6.  Other Considerations

   Another problem in an access network is that a host can contrive to
   receive packets destined for other hosts.  There are two situations.
   The first of these is the case where bothhosts are in a single
   collision domain, and a host can sniff packets sent to the other.
   Encrypting the packet to the host is the only way to prevent such
   sniffing and our mechanism provides good basics for such encrypting.
   Because the worst behaviour of an attacker is sniffing, stopping
   sniffing is necessary and sufficient.

   The other situation is thatthe hosts are in different collision
   domains.  An attacker can send spoofed ND message to the router in
   order to get packets addressed to another host.  Using SEND is a good
   choice to prevent such attacks.  Attacks in such situation are more
   serious because the victim cannot communicate normally and its IP
   could be used by others without it being aware.






















Bi, et al.              Expires January 28, 2009               [Page 17]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


6.  Comparision with Charter

   This mechanism is mostly consistent with the charter.  Though we only
   showed the mechanism satisfied all address allocation method, it can
   be used in other situations described in the charter, too.  This
   document doesn't explain the applicability in all the situations,
   since actually it's very obvious.

   The gap from this mechanism to the requirement of the charter is
   "host change".  Although the phase of address authorization can be
   regarded as the extension of SEND and the phase of address
   authentication can be regarded as the extension of IPSec, the charter
   also prohibits "externsions of current protocols".  We will discuss
   the necessity of "host change" below.

   We extend the concept of packet to be all the infomation the
   checkpoint gets with the packet, for example, the switch port is also
   thought to be the content of the packet.It is obvious that there can
   be no perfect filtering mechanism if any two nodes can send the same
   packets to the checkpoint.  The "perfect filtering" means any packet
   can be determined to be valid or not correctly.  Though a node can
   set the content of the packet above physical layer arbitrarily, it
   can not determine the port from which the packet is received by the
   switch.  Thus the switch port can be used to distinguish packets.
   However, if more than one nodes share a port, they have the ability
   of spoofing each other's addresses.  Only a strict one-one mapping
   from port to node can be used to achieve perfect filtering.  Actually
   switch port and interface of router are the only two elements that
   are unspoofable(if other element is found, there will be a new
   filtering mechanism).  The number of router interface is too rare to
   achieve a fine granularity filtering.  The switch port is actually
   the only information can be used to achieve a fine granularity
   filtering.  So once there is no strict one-one mapping from port to
   node, a host level perfect filtering is impossible.

   There is another kind of filtering we call "probability perfect
   filtering".  In a probability perfect filtering mechanism, a node
   still has the ability of generating a "valid" forged packet, but the
   probability is very low.  A signature-verification mechanism is a
   typical probability perfect filtering mechanism.  In a probability
   perfect filtering mechanism, the sender must have the knowledge of
   how to make the space of its valid packets to be very sparse to avoid
   spoofing attack, so the sending node must be modified.  Though there
   is a mechanism that doesn't modify the host end to enable
   filtering[hop count filtering], the knowledge used in filtering(the
   ttl value) is not secure and the mechanism is very vulnerable.

   Therefore, we think the limitation in the charter should be relaxed



Bi, et al.              Expires January 28, 2009               [Page 18]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


   to accept other mechanisms not based on filtering at switch port.


















































Bi, et al.              Expires January 28, 2009               [Page 19]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


7.  Acknowledgements

   The authors would like to acknowledge the contributors who provided
   helpful inputs on earlier versions of this document and Mark Williams
   who provided editorial support.

   The author gratefully acknowledges the contributions of Fred Baker,
   Jari Arkko, Christian Vogt, Xing Li, Pekka Savola, Lixia Zhang, Yan
   Shen, Lizhong Xie.










































Bi, et al.              Expires January 28, 2009               [Page 20]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


8.  References

   [CGA]      "RFC 3972: Crystographically Generated Addresses(CGA)",
              March 2005.

   [Privacy]  IBM, "RFC 3041: Privacy Extensions for Stateless Address
              Autoconfiguration in IPv6", January 2001.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [SAC]      "RFC 2462: IP Address Autoconfiguration", December 1999.

   [SEND]     Ericsson, "RFC 3971: SEcure Neighbor Discovery",
              March 2005.

   [Stateful DHCP]
              Cisco, "RFC 3315: Dynamic Host Configuration for IPv6",
               2003.

   [Stateless DHCP]
              Cisco, "RFC 3716: Stateless Dynamic Host Configuration
              Protocol(DHCP) service for IPv6",   2004.




























Bi, et al.              Expires January 28, 2009               [Page 21]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


Authors' Addresses

   Jun Bi
   CERNET
   Network Research Center, Tsinghua University
   Beijing  100084
   China

   Email: junbi@cernet.edu.cn


   Jianping Wu
   CERNET
   Network Research Center, Tsinghua University
   Beijing  100084
   China

   Email: jianping@cernet.edu.cn


   Guang Yao
   CERNET
   Network Research Center, Tsinghua University
   Beijing  100084
   China

   Email: yaog@netarchlab.tsinghua.edu.cn
























Bi, et al.              Expires January 28, 2009               [Page 22]


Internet-Draft            draft-bi-savi-csa-00                 July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.











Bi, et al.              Expires January 28, 2009               [Page 23]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/