Last Call Review of draft-ietf-csi-proxy-send-

Request Review of draft-ietf-csi-proxy-send
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-07-13
Requested 2010-06-09
Authors Marco Bonola, Suresh Krishnan, Alberto Garcia-Martinez, Julien Laganier
Draft last updated 2010-07-11
Completed reviews Secdir Last Call review of -?? by Sandra Murphy
Assignment Reviewer Sandra Murphy
State Completed
Review review-ietf-csi-proxy-send-secdir-lc-murphy-2010-07-11
Review completed: 2010-07-11


This is a review of draft draft-ietf-csi-proxy-send-04.txt.

I have reviewed this document as part of the security directorate's 

ongoing effort to review all IETF documents being processed by the IESG. 

These comments were written primarily for the benefit of the security area 

directors. Document editors and WG chairs should treat these comments just 

like any other last call comments.

This document provides new Neighbor Discovery options that will secure 

proxied Neighbor Discovery messages.  It is an update to:

RFC4861: Neighbor Discovery in IPv6
RFC4389: Neighbor Discovery Proxies (ND Proxy)
RFC3971: Send Neighbor Discovery (SEND)

This draft relies on draft draft-ietf-csi-send-cert-04.txt.

The need for new mechanisms for security for proxied messages is explained 

in draft-ietf-csi-sndp-prob-04.txt.

I've read all of these, but it is pretty new to me, so I could have missed 


The Neighbor Discovery protocol communicates link-level addresses in the 

protocol messages.  The ND Proxy extension would make changes to those 

fields.  SEND, which secures the base ND protocol, relies on the sender of 

a message computing a signature associated with the source IP address of 

the message.  Any ND Proxy changes to messages would invalidate the 

signature and the ND Proxy itself could not generate a new signature 

(since it would not have the private key associated with the source IP 

address).  This draft introduces a Proxy Signature (PS) option to secure 

the proxied messages.

RFC3971, the base SEND spec, defines a new Router Authorization 

Certificate profile, dependent on RFC3779, which authorizes the router to 

act as a router and act for certain prefixes.  Message authorization in 

SEND of some ND messages checks the prefixes listed in the certificate 

against the prefixes mentioned in those messages.  There is no explicit 

representation in the certificate of the authority to act as a router. 

Possession of the certificate in SEND serves as implicit authorization to 

act as a router, as that was the only authorization defined.

With the introduction of proxies, there was a need to distinguish the 

various roles that a node might have in the network.  No longer is 

possession of a certificate adequate authorization.  The draft 

draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to distinguish 

three different roles: router, proxy and owner.  That draft notes that 

multiple key purposes are possible.  I believe that it is also possible to 

have single roles  so a node could be a proxy but not a router.

With the extensions of the csi-send-cert draft, possession of a 

certificate is no longer proof of any particular authorization.  It seem 

clear to me that the authorization validation described in RFC3971 is no 

longer sufficient.  I believe that a discussion is needed of what messages 

require or allow each particular key purpose authorization.  Issuing an 

RA, for example, seems likely to require the "router" value of the key 

purpose field, if the new certificate format was used for authorization. 

Issuing an NA may require the "owner" value of the key purpose field, if 

the new certificate format was used for authorization rather than a CGA. 

I do not know if that discussion would be more appropriate here or in the 

csi-send-cert draft, or another draft entirely that updates RFC3971 


If a SPND proxy was using SEND to communicate with other nodes that 

understood SPND, would it be OK to use a new format cert (with the 

"router" KeyPurposeId) as a router certificate for the SEND RSA Signature 


This draft validates the use of its new PS option against a proxy 

KeyPurposeId in the certificate.  However, I could not find that it 

validates the prefixes in the proxied messages against the prefixes 

mentioned in the certificate.  Surely it should.  RFC3971 requires that 

the prefixes in a PI option match the router cert prefixes, but Im not 

sure that carries through to the proxied messages or those (like NA) that 

refer to an address and have no PI option.

I was curious as to the topological scenarios possible with proxies. 

RFC4861 notes that multiple proxies might respond on a single link, 

draft-csi-sndp-prob-04.txt discusses proxies that are nested, RFC4389 says 

that a proxy never receives RAs from other proxies (which restricts 

topologies), and this draft mentions proxying messages that already 

contain a PS option.  In Sec 5.2.2 of this draft, steps 6 and 7 of the 

rules for receivers of the Proxy Signature option imply that there might 

be multiple proxies on a link as well as proxy responses colliding with 

direct responses.  While there is a discussion of scenarios for proxying 

ND messages, they are not discussions of topologies of the proxies 

themselves.  I believe that I would have benefited from an explanation of 

the topology envisioned here.

Each SPND proxy must be able to distinguish secure nodes (RFC3971 or SPND 

nodes) from insecure nodes (non-SEND) on the link for which it serves as 

proxy.  It decides whether to securely proxy ND messages received from 

those nodes based on that info.  Is there any thought as to how the SPND 

proxy would know this?  If this is manual configuration, that could be a 

lot of work or impossible depending on the scenario.  And if there are 

multiple proxies on the link in some topologies, they must be consistent.

I was curious as to whether unsigned ND messages could be proxied securely 

by a SPND node.  Section 5.2.1 p 10 says the PS option MUST be added, 

which satisfied me, but then Section 7.2 p 20 says there are cases where 

the PS option MUST NOT be added.  If thats a contradiction, it needs to 

be addressed.

The text seems to make a distinction between "locally generated"/"issued" 

messages for a proxied address and "forwarding" or "translating" a message 

from a proxied address.  I was never certain what cases might cause the 

local generation of an address.  RFC4389 seem to me to refer only to the 

forwarding of messages.  Perhaps the "local generate" term refers to the 

scenario discussion in section 6.2 of Proxy Mobile IP, perhaps the term 

refers to some of the exchanges in RFC4389 proxying.  Im not sure.

After reading this, I was not sure that I had an adequate idea of the 

error processing when different information has the potential to conflict. 

I was particularly interested in the RA message. RFC4389 introduces a "P" 

bit for the RA messages to indicate a proxied message.  This draft 

introduces a PS option to secure proxied messages.  The new cert format 

has a "proxy" value for the KeyPurposeId.  I tried to work out the 


P bit   PS opt   cert:"proxy" action
  0       no         no       no proxy needed (can use 3791)
  0       no         yes      no proxy needed (can use 3971)
  0       yes        no       silent discard of message
  0       yes        yes      weird but OK?
  1       no         no       "unsecured", even if 3971 signed?
                              cert says not a proxy, so drop?
  1       no         yes      "unsecured", even if 3971 signed?
                              If 3971 signed, check 3971 cert
                              prefixes or new cert prefixes?
  1       yes        no       silent discard of message
  1       yes        yes      secure proxy  all OK

As acknowledged in the Section 7.1, a RFC3971 message from a RFC3971 node 

to another RFC3971 node proxied through a SPND proxy appears unsecured to 

the receiver.  Thats no worse than proxying the message through a RFC3971 

proxy, so no harm done, for most messages.  For Router Solicitation 

messages, which according to RFC3489 dont get altered and can retain 

their signatures, the outcome is worse. I think.

Detailed comments:

Sec 4, p 6:

      Proxy ND's certificate.  When a ND message contains a PS option,
      it MUST NOT contain CGA and RSA Signature options.  This option
      can be appended to any ND message: NA, NS, RS, RA and Redirect.

Is that a "MAY" be appended?  Page 10 says "MUST" be added, but section 

7.2 p 20 talks of cases where it MUST NOT be added.

   o  A modification of the SEND processing rules for all ND messages:
      NA, NS, RS, RA, and Redirect.

This draft and RFC4389 do not mention  if the proxied message is a NA, 

and the proxy is a router, does the router bit get set?

Sec 5.2.1 p 10

5.2.1.  Processing rules for senders

   A ICMPv6 message sent by a Secure ND Proxy for a proxied address MUST
   contain a PS option and MUST NOT contain either CGA or RSA Signature

Note contradiction in section 7.2 p 20.

Sec 5.2.1 p 11

       C.  If the Secure ND Proxy is forwarding a SEND message already
           containing a PS option, first the authenticity of the
           intercepted message is verified as specified in Section 5.2.2
           of this specification.  If the SEND message is valid, the
           original PS option MUST be removed from the message.  The
           intercepted message is finally modified as described in
           Section 4 of the ND Proxy specification [RFC4389].

Does this disagree with the RFC4389 statement that RA messages can not be 

received from other proxies?  That is, if an RA message P bit is set (and 

if it contains a PS option, one hopes the P bit is set), RFC4389 sec says the interface must not be used as a proxy interface.

   2.  Timestamp and Nonce options MUST be included according to the
       rules specified in SEND [RFC3971].  The value in the Timestamp
       option MUST be generated by the proxy.  If the proxy is
       forwarding a message, the Nonce value in the proxied message MUST
       be the same as in the forwarded message, otherwise it is
       generated by the proxy.

What is the "otherwise" here?  If the proxy is *not* forwarding, which 

might be if it is "locally generating" a message?  If the Nonce is not 

present in the forwarded messages?

Sec 6.2 p 16

This scenario seems to be using the SPND feature because the MAG is using 

a source address that does not really belong to it.  It is not forwarding 

any ND messages.  So perhaps this is the case where the "locally 

generated" terminology applies.

   To provide SEND protection, each MAG is configured to act as a proxy
   by means of a certificate associated to the PMIPv6 domain,
   authorizing each MAG to proxy securely ND messages.  In addition, the
   certificate must also authorize the MAG to advertise prefixes.  Note
   that the inclusion of multiple KeyPurposeId values is supported by

I believe that means that the new cert format must show both the router 

and the proxy KeyPurposeID values because it is generating a RA.  But no 

such check is mentioned anywhere.

Sec 6.2 p 16

   A node receiving a message from the MAG containing the PS option MUST
   apply the rules defined in Section 5.2.2.  Note that unsolicited
   messages sent by MAG are validated by the host according to timestamp
   values specific to the MAG serving the link, not to any other MAG to
   which the host has been connected before in other links.

The host does not see any difference in the MAG, since the MAG is using 

the same source IP address as all other MAGs to which the host has been 

connected.  According to my reading of RFC3971, that means that theres a 

chance that unsolicited messages from the MAG would appear stale  as long 

as the unsolicited message was received before a solicited advertisement. 

Receipt of a solicited advertisement should update the timestamp at the 

host, based on the nonce matching, by RFC3971 rules

Sec 6.3 p 17/18

   A Secure ND Proxy shall parse any IPv6 packet it receives on a proxy
   interface to check whether it contains one of the following secured
   ICMPv6 messages: NS, NA, RA, or Redirect.

This seems to disagree with Section 5.2.1, p 10, which says the PS option 

is added to *all* messages.  However, it does agree with the discussion in 

section 7.2 p 19/20, which says that the PS option is only generated on 

behalf of RFC3917 nodes and SPND nodes.

Section 7.1 p 19

   In the scenarios in which the proxy translates ND messages, the
   messages to translate can either be originated in a RFC3971 node or
   in an SPND node, without interoperability issues.

The discussion immediately above this text says that RFC3971 nodes drop a 

PS option in a proxied message and treat the message as unsecured, so I am 

not sure what this is talking about.  A secure proxied NA reply, for 

example, would appear unsecured to the RFC3971 host and secure to the SPND 

proxied host. Is "translates" an ND message different from 

"forwards"/"proxies" an ND message  i.e., the PS option is not applied?

sec 7.2 p 20

   Therefore, the Secure ND Proxy MUST generate messages containing the
   PS option for SPND and RFC3971 hosts, and MUST NOT generate messages
   containing the PS option for non-SEND nodes.

This (and other places in the subsequent paragraphs) seems to contradict 

sec 5.2.1 p 10 which says the PS option is a MUST, period.

What does the "for SPND and RFC3971 hosts" and the "for non-SEND hosts" 

mean?  I believe that it means that the proxy is forwarding messages on 

their behalf.  The use of the term "generate" here doesnt seem to mean 

the same as "locally generated" elsewhere.

I am not sure how the SPND would know which of the nodes on the proxy 

interface were non-SEND, RFC3917, or SPND nodes.  But if it can be 

configured with that information, could it also be configured to know the 

status of nodes on the outgoing interface?  It might then detect that 

doing the computation to add the PS option was a waste of effort because 

there were no SPND nodes on that side.

If the RFC3971 node produces a solicitation that needs to be forwarded 

through the SPND proxy, and the SPND proxy forwards the advertisement it 

received in reply along with the PS option, the RFC3971 will drop the PS 

option.  True?  Should the SPND still produce the (wasted) signature?

Sec 7.2 page 20

  o  For translating ND messages for nodes that can arrive to the link
      in which the proxy operates,

   o  For synthesizing ND messages on behalf of remote nodes,

I think "translating" here means forwarding through the proxy and doing 

the RFC4389 changes, while "synthesizing ND messages" means the mobile 

node scenarios where no message is received for forwarding but one is 

created (PMIPv6 and MIPv6?).

An explanation of this difference and a consistent set of terms would have 

helped a lot.

   o  For translating ND messages for nodes that can arrive to the link
      in which the proxy operates, the rule can be easily applied: only
      messages validated in the Secure ND Proxy according to the SEND
      specification [RFC3971] MUST be proxied securely by the inclusion
      of a PS option.  Unsecured ND messages could be proxied if
      unsecured operation is enabled in the proxy, but the message
      generated by the Secure ND Proxy for the received message MUST NOT
      include a PS option.

Is it possible for a proxy to receive a message with a PS option? 

Previous text (sec 5.2.1 part C) seems to indicate so.  If the "MUST be 

proxied securely" applies to SPND protected messages as well as RFC3971 

protected messages, then this case is the same as the previous paragraph 

"MUST generate messages containing the PS option for SPND and RFC3971 

hosts . . .".  Unless this is a difference between translating messages 

and generating messages, of course.

Sec 8 p 22

            However, when two on-link hosts communicate using
   their respective link-local addresses, the threats involved with a
   compromised router and a compromised proxy ND differs because the
   router is not able to siphon off traffic exchanged between the hosts
   or mount a man-in-the-middle attack, while the proxy ND can, even if
   the hosts use SEND.

This should be explained in more detail.  I believe that the reason is 

that a SEND router would not be able to produce a NA reply to an NS that 

would be believed, but the SPND could pretend to be proxying a NA reply 

believably  as long as the recipient used SPND and could accept the PS 


   Proper configuration of when the PS option must or must not be
   included, depending on the proxied nodes being SEND or non-SEND may
   result in security considerations which are discussed in Section 7.

This is pretty contorted.  I believe that this is trying to say that 

Section 7 discusses some of the security considerations resulting from the 

decision to append or omit PS protections depending on the SEND awareness 

of the proxied nodes.  But Im not sure.

   Attacks to the timestamp of the secured ND message can be performed
   as described in section 7.3 of [I-D.ietf-csi-sndp-prob].

I found that section of that draft to be particularly unclear.  And it is 

not normatively cited here.  Im not saying that it should be, but if that 

draft does not progress (giving opportunity to improve the discussion), 

the reader of this draft would be lost.  Is there any way to summarize the 

vulnerabilities so that the reader of this draft have some hint of what 

can go wrong and why?


Sec 5.2.2 p 12

       the IP of node for which the message is proxied.  In this way, a
        the IP address of a node

       cached link-layer address created securily by means of RSA

Sec 6.1 p 13-14

Sometimes the Home Address is abbreviated HoA and sometimes as HA

Sec 6.2 p 16

   link to which the MN is attached to, to be generated by the LMA when
        to which the MN is attached,
   the MN first attach to a PMIPv6 domain,

sec 7.2 p 20

   options on behalf of nodes with SEND capabilities (i.e. that they
   could use SEND to defend their messages if being in the same link
                                              present on
   than the proxy, either RFC3971 nodes or SPND nodes).
   with <or "as">

sec 7.2 p 20

                                      Not using the PS option for a
         RFC3971 or SPND MN would make more vulnerable the address in
         the home link when the MN is away than when it is in the home

This is a bit awkward.  I suggest moving the "more vulnerable" part" so 

that it reads:

Not using the PS option for a RFC3971 or SPND MN would make the address in 

the home link more vulnerable when the MN is away than when it is in the 

home link

Sec 8 p 22

   The security of proxied ND messages not including a PS option is the
   same of an unsecured ND message.  The security of a proxied ND
   message received by a non-SEND host or RFC3971 host is the same of an
   unsecured ND message.

Sec 8 p 22

   Attacks to the timestamp of the secured ND message can be performed