[CGA-EXT] [draft-ietf-csi-proxy-send-01] review

[Jean-Michel Combes <[e-mail]>]

Hi,

Here are some comments/questions about this draft (sorry if some have
already been submitted/solved on the ML):


4.  Application Scenarios

<JMC>
These 3 scenarios are already documented in "Securing Neighbor
Discovery Proxy Problem Statement" [draft-ietf-csi-sndp-prob-03], so I
think they may be removed from the document or do you assume that your
solution only solves these scenarios (i.e. your solution cannot solve
IKEv2 scenario and Anycast scenario described in
[draft-ietf-csi-sndp-prob-03] but I don't think so :))
<JMC>


         Link 1                                               Link 2

         Host A                   ND Proxy (P)                Host B
           |                          |                          |
           | SRC = A                  |                          |
           | DST = solicited_node(B)  |                          |
           | ICMPv6 NS                |                          |
           | TARGET = B               |                          |
           | SLLAO = B_LL             |                          |
           |------------------------->|                          |
           |                          | SRC = A                  |
           |                          | DST = solicited_node(B)  |
           |                          | ICMPv6 NS                |
           |                          | TARGET = B               |
           |                          | SLLAO = P_LL             |
           |                          |------------------------->|
           |                          |                          |
           |                          | SRC = B                  |
           |                          | DST = A                  |
           |                          | ICMPv6 NA                |
           |                          | TARGET = B               |
           |                          | TLLAO = B_LL             |
           |                          |<-------------------------|
           | SRC = B                  |                          |
           | DST = A                  |                          |
           | ICMPv6 NA                |                          |
           | TARGET = B               |                          |
           | TLLAO = B_LL             |                          |
           |<-------------------------|                          |
           |                          |                          |


                      Figure 1: Proxy ND operations

<JMC>
s/TLLAO = B_LL/TLLA = P_LL/
<JMC>

4.2.  Scenario 2: Mobile IPv6

  The Mobile IPv6 protocol [RFC3775] allows a mobile node (MN) to move
  from one link to another while maintaining reachability at a stable
  address, the so-called MN's home address (HoA.)  When a mobile node
  attaches to a foreign network, all the packets sent to the MN's HoA
  and forwarded on the home link by a correspondent node (CN) or a
  router are intercepted by the home agent (HA) on that home link,
  encapsulated and tunneled to the mobile node's registered care-of
  address (CoA.)

<JMC>
s/registered care-of address (CoA.)/registered care-of address (CoA).
<JMC>

  It is not possible to apply the current SEND specification to protect
  the NA message issued by the HA.  To generate an ICMPv6 NA with a
  valid CGA option and the corresponding RSA Signature option, the HA
  needs knowledge of the private key related to the MN's
  Cryptographically Generated Address (CGA.)  Any ICMPv6 NA without a
  valid CGA and RSA signature option is to be treated as insecure by a
  SEND receiver.

<JMC>
s/the MN's Cryptographically Generated Address (CGA.)/the MN's
Cryptographically Generated Address (CGA).
<JMC>


  Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is a network-based
  mobility management protocol that provides an IP mobility management
  support for MNs without requiring MNs being involved in the mobility
  related signaling.  The IP mobility management is totally hidden to
  the MN in a Proxy Mobile IPv6 domain and is performed by two
  functional entities: the Local Mobility Anchor (LMA) and the Mobile
  Access Gateway (MAG.)

<JMC>
s/[I-D.ietf-netlmm-proxymip6]/[RFC5213]
s/Mobile Access Gateway (MAG.)/Mobile Access Gateway (MAG).
<JMC>

  When the MN connects to a new access link it will send a multicast
  ICMPv6 Router Solicitation (RS.)  The MAG on the new access link,
  upon detecting the MN's attachment, will signal the LMA for updating
  the binding state of the MN (Proxy Binding Update - PBU) and once the
  signaling is complete (Proxy Binding Ack - PBA - received), it will
  reply to the MN with a ICMPv6 Router Advertisement (RA) containing
  its home network prefix(es) that were assigned to that mobility
  session, making the MN believe it is still on the same link and not
  triggering the IPv6 address reconfiguration (figure Figure 3.)

<JMC>
s/ICMPv6 Router Solicitation (RS.)/ICMPv6 Router Solicitation (RS).
<JMC>

  o  A certificate authorizing an entity to act as an ND proxy is
     introduced.  This is achieved via specifying explicitly in the
     X509v3 certificate the purpose for which the certificate is
     issued, as described in a companion document
     [I-D.krishnan-cgaext-send-cert-eku].  Briefly, two KeyPurposeID
     values are defined: one for authorizing routers, and one for
     authorizing proxies.  The inclusion of the proxy authorization
     value allows the certificate owner to perform proxying of SEND
     messages for a set of prefixes indicated in the same certificate.

<JMC>
s/[I-D.krishnan-cgaext-send-cert-eku]/[draft-ietf-csi-send-cert-01]

s/ Briefly, two KeyPurposeID values are defined: one for authorizing
routers, and one for authorizing proxies./ Briefly, one KeyPurposeID
value is defined for authorizing proxies.
I think that avoids to mention the third KeyPurposeID (i.e.
authorization for a node to use an address range)
<JMC>

  o  A new option called Proxy Signature option (PSO) is defined.  This
     option contains the key hash value of the Secure Proxy ND's public
     key and the digital signature computed over the SEND message.  The
     key has value is computed over the public key within the Secure
     Proxy ND's certificate.

<JMC>
s/The key has value is computed/The key hash value is computed
<JMC>


  This is accomplished by signing the message with the public key of
  the authorized Secure Proxy ND.  The signature of the neighbor
  discovery proxy is included in a new option called Proxy Signature
  option (PSO.)  The signature is performed over all the NDP options
  present in the message and the PSO is appended as the last option in
  the message.

<JMC>
s/The signature of the neighbor discovery proxy is included in a new
option called Proxy Signature option (PSO.) /The signature of the
neighbor discovery proxy is included in a new option called Proxy
Signature option (PSO).
<JMC>

     1.  The 128-bit CGA Message Type tag [RFC3972] value for Secure
         Proxy ND, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804 (The tag
         value has been generated randomly by the editor of this
         specification.)

<JMC>
s/The tag value has been generated randomly by the editor of this
specification.)/The tag value has been generated randomly by the
editor of this specification).
<JMC>

     This field starts after the Key Hash field.  The length of the
     Digital Signature field is determined by the length of the RSA
     Signature option minus the length of the other fields (including
     the variable length Pad field.)

<JMC>
s/(including the variable length Pad field.)/(including the variable
length Pad field).

  1.  The SEND message is constructed without the PSO as follow:

      A.  If the Secure Proxy ND is locally generating the SEND message
          for a proxied address, the message is constructed as
          described in Neighbor Discovery for IP version 6
          specification [RFC4861].

      B.  If the Secure Proxy ND is forwarding a SEND message, first
          the authenticity of the intercepted message is verified as
          specified in SEND specification [RFC3971] Section 5.  If the
          SEND message is valid, any CGA or RSA option MUST be removed
          from the message.  The intercepted message is finally
          modified as described in Section 4 of the ND Proxy
          specification [RFC4389].

<JMC>
Maybe, to add the case where a Secure Proxy is forwarding a SEND
message, already forwarded by another Secure Proxy ND:

C.  If the Secure Proxy ND is forwarding a SEND message already
containing a PSO, first
the authenticity of the intercepted message is verified as specified
in Section 6.2.2 of this draft.  If the SEND message is valid, the PSO
MUST be removed from the message.  The intercepted message is finally
modified as described in Section 4 of the ND Proxy specification
[RFC4389].
<JMC>

  If, on the other hand, a message does not include a PSO, then the
  Secure Proxy ND support doens't introduce any further security issues
  since this specification does not modify the SEND processing rules if
  an ICMPv6 ND message does not contain a PSO.  Thus, the same security
  considerations than that of SEND applies (cf. Section 9 of the SEND
  specification [RFC3971].)

<JMC>
I don't agree with the fact that this mechanism doesn't bring any
further security issues. I would add text about the fact that the
Secure Proxy ND's certificate provided to the Proxy ND router weakens
the security in comparison to a classical SEND deployment (i.e.
without Proxy ND entity): now, in the case where a Secure Proxy ND is
compromised, it is able to launch a DoS attack even against a ND
process between 2 nodes on a same link (e.g. in the figure below, a
attack may be launch against a ND process between node A and node B).

                     +-----------------+
----------------------| Secure Proxy ND |----- Node C
   |         |       +-----------------+
 Node A    Node B

So, maybe, it would be useful to add text here to explain the issue
and to add text at the beginning of the Section 6.2.2 maybe as
follows:
When a node receives at the same time a ND message protected by SEND
[RFC3971] and a ND message protected by PSO on the same subject (e.g.
a NA message after a solicited NS) but with different information
(e.g. the NA messages don't contains the same information for a same
solicited NS), the node MUST treat the message secured with SEND and
it MUST silently ignore the one secured with PSO.
<JMC>

Thanks in advance for your reply.

Best regards.

JMC.