Re: [secdir] (MAIN) secdir review of draft-ietf-csi-proxy-send-04

[Alberto García <[e-mail]>]

Hi,

I have posted a new version of the draft, draft-ietf-csi-proxy-send, version
-05, with the changes resulting from this review, which have also resulted
in a new version of draft-ietf-csi-send-cert, recently issued.

 

Regarding to the comments made by Sandra, here I enclose (inline) a summary
of the changes being made according to them (for those items which I don't
explicitly answer in this email, I have preferred not to make any change).

 

I hope that the document addresses your concerns and it is ready to proceed
- however, if you have any other comments, please let me know.

 

|  -----Mensaje original-----

|  De: Alberto García [mailto:[e-mail]]

|  Enviado el: martes, 06 de julio de 2010 17:33

|  Para: 'Sandra Murphy'; [e-mail]; [e-mail];
draft-ietf-csi-proxy-

|  [e-mail]

|  CC: [e-mail]

|  Asunto: RE: (MAIN) secdir review of draft-ietf-csi-proxy-send-04

|  

|  Hi Sandra

|  

|  First of all, thanks for your thorough review. You have included very
relevant

|  comments to improve the document.

|   

|  I think the first part of this email should be discussed with authors of
draft-ietf-

|  csi-send-cert, so I have split in two pieces this email, and copied the
authors of

|  draft-ietf-csi-send-cert in the part affecting them.

 

Sandra made some comments about the need for clarifying authorization
capabilities. 

The changes to address this issue affect draft-ietf-csi-send-cert-07 and
draft-ietf-csi-proxy-send

 

In draft-ietf-csi-send-cert-07 (document specifying the certificate
enhancements for proxy support): Now there are 2 KeyPurposeIDs (instead of
1) for proxy operation to separate the authorization to sign RA and Redirect
(id-kp-sendProxiedRouter), and to sign NS, NA and RS messages
(id-kp-sendProxiedOwner). The detail of which messages can be signed and for
which purpose is also included.

 

In draft-ietf-csi-proxy-send-05 we have made changes to detail this in

- 'Processing rules for senders'

   "A Secure ND Proxy MUST NOT use a key to sign NDP message types which

   do not correspond to the authorization granted to the considered key.

   NA, NS and RS messages MUST be signed with a key corresponding to a

   Secure Proxy ND certificate with a KeyPurposeId value

   [I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the source

   addresses of the messages MUST be encompassed in the prefix

   associated to the certificate.  RA and Redirect messages MUST be

   signed with a key corresponding to a Secure Proxy ND certificate with

   a KeyPurposeId value of id-kp-sendProxiedRouter.  The prefix included

   in the RA message for on-link determination and/or stateless address

   autoconfiguration, and the Target Address of the Redirect message,

   MUST be encompassed in the prefix associated to that certificate."

 

- 'Processing rules for receivers'. Similar to the previous one

- Modification of the application scenarios to detail how the certificates
are configured. (for example, for the MIPv6 case only id-kp-ProxiedOwner is
required, while for the other two both id-kp-sendProxiedRouter and
id-kp-sendProxiedOwner are used)

- A paragraph in the security considerations section stating that the
authorization capabilities provided by the KeyPurposeId should not exceed
the minimum required by the scenario

 

 

|  

|  The rest of the text is discussed in this email (I've included in the
subject of this

|  email '(MAIN)' to distinguish both threads).

|  

|  |  -----Mensaje original-----

|  |  De: Sandra Murphy [mailto:[e-mail]]

|  |  Enviado el: viernes, 02 de julio de 2010 2:31

|  |  Para: [e-mail]; [e-mail];
[e-mail]

|  |  Asunto: secdir review of draft-ietf-csi-proxy-send-04

|  

|  

|  |  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 I'm
not

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

|  |  refer to an address and have no PI option.

|  

|  Yes, definitely prefixes should be checked. New text should be added,
since

|  RFC3971 did not detail how certificates could be used to substitute CGA.

 

Done in previous change

 

|  

|  |  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

|  

|  I understand (RFC4389: 4.1.3.3) that there is a 'direction' in which RA
flows

|  (from upstream to downstream), and there are rules to control that only
the

|  appropriate interface propagates RA.

|  

|  |  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.

|  

|  

|  Well, we thought that a generic discussion of the topologies of the
proxies would

|  have been out of the scope of the document and the working group.

|  

|  |  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.

|  

|  

|  Well, I think this is specific to each deployment scenario, and I think
it is risky to

|  include text going further than presenting the security considerations.

|  

|  Considering the 3 scenarios presented in the draft:

|  

|  - RFC4389 involves translating messages, so it is trivial to know the
SEND/non-

|  SEND nature of the node. This is general for translating scenarios, as
commented

|  in the draft in section 7.

|  

|  - PMIPv6 is very infrastructure dependent. The proxied element is the
router. I

|  would expect the provider to know if all MAGs support SEND or not (if any
does

|  not support SEND... then non-SEND operation should be used).

|  

|  - MIPv6. Here hosts are proxied, and the HA synthesizes messages on
behalf of

|  the hosts. This is for me the most complex scenario, and I'm not aware of
any

|  other solution than any kind of manual configuration (besides all nodes
being

|  required to be SEND).

|  

|  I think the previous info can be derived directly from the text of the
draft.

|  

|  However, new scenarios may arise, and this could be handled easier. For

|  example, assume proxy elements for saving energy by allowing hosts to go
to

|  sleep when not being heavily used (a-la ProxZZZy - www.ecma-

|  international.org/publications/files/ECMA-ST/ECMA-393.pdf). In this case
the host

|  would be in the same link as the proxy, so previous communication should
have

|  occurred (in particular, to allow the host to tell the proxy that it goes
to sleep),

|  so the proxy may know in advance if the host is SEND or not.

|  

|  

|  

|  |

|  |  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 that's a contradiction, it needs
to

|  |  be addressed

|  

|  

|  Well, 5.2.1 describes operation considering that the originating message
is

|  protected by SEND, so the proxied message is also secured. So it MUST be
added

|  to be secured. I can add some words to clarify that.

|  

|  The part in which non-SEND hosts appear is section 7.

|  

|  This structure is analogous to the SEND specification.

|  

In section 5.2.1, added comment at the end of paragraph:

   "A secured NDP 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 options.  Section 7 discusses in which cases a NDP message
   has to be secured in an scenario including non-SEND nodes."

 

 

 

|  

|  |  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.  I'm not sure.

|  

|  Well, what it is trying to say is not that the address is being generated
or not, but

|  the message.

|  

|  The "forwarding" or "translating" case stands for the case in which a
message is

|  received by the proxy through one interface, and relayed to other. This
is the

|  case of RFC4389.

|  

|  The "locally generated"/"issued" or "synthesized" stands for messages
that are

|  generated by the proxy without receiving a message from the proxy. This
is the

|  MIPv6 and PMIP case.

|  

|  Do you think it would be more clear if this is included in the
'Terminology'

|  section?

|  

 

'Translated NDP message' and 'Synthetic NDP message' have been included in
the 'Terminology' section. These terms are now used consistently all over
the document.

 

|  |

|  |  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

|  |  combinations:

|  

|  |

|  |  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

|  

|  

|  Well, the fourth case in the table needs some though, while the others
are ok:

|  

|  The "P" bit of RFC4389 is only meaningful for proxies, i.e. hosts does
not process

|  it: the way the behavior of the receivers is defined in section 4.1.3.3
is "When

|  [...] arrives on the upstream interface" or "[...] on the downstream
interface"...

|  The description always refers to upstream and downstream, which are only

|  relevant for RFC4389 proxies.

|  

|  Then, for hosts the first column is irrelevant.

|  

|  Assume an RFC 4389 proxy with SPND enabled receives any message (in this

|  case, the 3 'switches' - P bit, PS opt, cert opt- would be meaningful).

|  

|  First, security is checked, which means that the P bit should not be
processed

|  until the message is verified, and a "security level" ('secured' or
'unsecured') is

|  defined for the message. Then I don't think a table in which the three
elements

|  are mixed together is a good representation of the problem. Instead, I
think its

|  better to view the process as a sequence of tie-breaking rules: 5.2.2
specifies the

|  requirements for having a messages validated as secured. Rule #1 just
discards

|  parts of the message that must not be considered when analyzing its
security.

|  

|  Rule #2 requires a valid certificate with 'proxy' value, and this
certificate being

|  linked to the message through the 'Key Hash' field. If this fails, then
the message

|  is unsecured.

|  

|  The rest of the rules check for the validity of the PS option. So, I
would say:

|  

|  cert:"proxy"      PS opt              action

|  

|  no                    no                    unsecured

|  no                    yes                  unsecured

|  yes                  no                    This does not have much sense:
you cannot

|  know to which cert is referring a message if there is no PS opt with a
Key Hash

|  pointing to a cert.

|  yes                  yes                  secured

|  

|  Then, the question stated in your table: ""unsecured", even if 3971
signed?

|  |                                 cert says not a proxy, so drop?"

|  

|  Would be 'unsecured', and then discard or not according to the
configuration of

|  the host regarding to backward compatibility (accept 'unsecured' if
configured to

|  do so, and in any case do not replace 'secured' information with
'unsecured' one)

|  

|  Now we can look at the P (RFC4389) bit. The case in which a secured
message

|  from a proxy is received, but the bit P is set to 0... this MUST NOT have
been

|  generated by a RFC4389 proxy (since RFC4389 proxies always set the P
bit). It

|  could have been generated by other proxy type - for example, a PMIPv6
MAG,

|  which for the RFC4389 proxy would look as a 'regular' router.

|  

|  If the proxy were sure that only RFC4389 proxy operation is allowed, then
this

|  situation is really strange (a proxy that sends a RA message secured...
that

|  should be a RFC4389 proxy, but does not set the bit P to 1), and
probably, it

|  should discard the message.

|  

|  Does this fully address your question?

|  

|  

|  

|  Do you think it would clarify to add some text to the document? (I'm
thinking

|  specifically in the part of the scenarios, probably adding to section
6.3, 'rule' 1, in

|  which a summary of the processing which RFC4863 proxies do before sending

|  the packet, that the P bit must be set.

|  

|  And maybe a new sentence saying that proxies receiving this info, if they
are

|  sure that only RFC4389 proxy operation is allowed, could discard messages
with

|  valid PSO option but without the P bit? (<-- not sure that this is very
clarifying...)

|  

|  |  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.  That's 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 don't get altered and can retain

|  |  their signatures, the outcome is worse. I think.

|  

|  I see your point.

|  

|  RFC 4389, section 4.1 (and also draft-ietf-csi-proxy-send) states that

|  

|  "This document covers the following types:

|     Neighbor Solicitations, Neighbor Advertisements, Router

|     Advertisements, and Redirects. These packets are ones that can carry

|     link-layer addresses, and hence must be proxied [...]"

|  

|  But I think this is not completely true, since RFC4861 states that Router

|  Solicitations can also carry source link-layer addresses:

|  

|  "4.1.  Router Solicitation Message Format

|  

|  [...]

|  

|  Source link-layer address The link-layer address of the sender, if

|                       known.  MUST NOT be included if the Source Address

|                       is the unspecified address.  Otherwise, it SHOULD

|                       be included on link layers that have addresses."

|  

|  It is clear for me that if the RS message includes a "Source link-layer
address

|  option", it must also include a PS option.

|  

|  But, could a SEND-protected RS message which does not include a
link-layer

|  address be copied as-is in the other interface? I think yes, since CGAs
would be

|  validated consistently.

|  

|  This would be the device you mention as "RFC3971 proxy", which by the
way, I

|  don't think has been defined. I mean, should this "RFC3971 proxy" check
for the

|  validity of the original message, or just let it pass and let the
receiver doing the

|  check? I think it should check (as the SPND proxy does), but I don't have
a clear

|  opinion on this.

|  

|  Then, I see two options for proxying secure messages not including
link-layer

|  addresses:

|  

|  1- Process as defined for the SPND proxy (which is check for validity of
the

|  original message, include PS option...)

|  

|  2- check for validity of the original message, and if it is valid,
forward as-is

|  

|  The first option seems more homogeneous. The second one allows the
validation

|  of some messages by nodes which are RFC3971 but not SPND. However, this
is

|  only for a very limited subset of the proxied information, which is the
one not

|  including link-layer addresses.

|  

|  I tend to prefer 1, but without a clear opinion.

|  

|  What do you think?

|  

|  Once clarified, the text of the RFC4389 scenario should be updated.

|  

 

Done, (for Choice 1)

 

|  

|  |  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.

|  

|  MUST be added to be secured.

|  MUST NOT for non-SEND nodes.

|  

 

Changed

 

|  

|  

|  Obviously, (as commented above), a clarification saying that processing
rules of

|  section 5 are for generating/processing secured messages must be included

|  

|  

|  |      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?

|  

|  I think it should be set (I don't see any reason for not being set).

|  Not sure if I should 'complement' RFC4389 in this document...

|  

|  |

|  |  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

|  |      options.

|  |

|  |  Note contradiction in section 7.2 p 20.

|  

|  Commented above

|  

|  

|  |  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

|  |  4.1.3.3 says the interface must not be used as a proxy interface.

|  

|  No, I understand in a different way: RA messages can be proxied many
times.

|  Assume

|  

|                         I1  I2

|  

|  Router ------ P1 ------- P2 -----P3

|  

|  

|  With I1 being the interface of P2 connected to the router, and I2 the
interface of

|  P2 connected to P3.

|  

|  What RFC4389 says is that when P1 receives a RA, then it cannot be
proxied to

|  I1 (but it can to I2)

|  

|  

|  I think there is no disagreement.

|  

|  

|  |      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?

|  

|  

|  'Otherwise' refers to synthesizing locally the message. I thing this two
behaviors

|  ('forwarding', 'generating locally') should be presented more clearly
before this

|  rule (although this concepts are somehow presented in rule 1).

|  

|  'Otherwise' does not refer to the nonce. RFC3971 states that it is not
present for

|  unsolicited advertisements. If a proxy is receiving a message to be
forwarded

|  without the nonce (or otherwise), where it should be, it will be marked
as

|  unsecured. Then the proxy will include it "according to the

|        rules specified in SEND [RFC3971]", as says the previous text.

|  

|  I can also change 'otherwise' with "If the proxy is synthesizing a
message .", so

|  ambiguity is definitely resolved.

 

Done. Also the 'forwarding'/'generating locally' terms have been removed
(see a comment above)

 

|  |

|  |  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.

|  

|  Yes, this is one of the cases (the other is MIPv6 - note that in this
case, although

|  the MN and HA is communicating, when a host in the link of the HA
generates a

|  NS for the MN, the HA responds without retransmitting the request to the
MN

|  and then waiting back for the answer)

|  

|  |      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-D.ietf-csi-send-cert].

|  

|  |  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.

|  

|  Yes, you are right. Once clarified which KeyPurposeId should be used,
this

|  should be changed also

|  

 

This has been already clarified 

 

|  

|  |  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
there's 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

|  

|  Well, there is a risk that unsolicited messages where considered
unsecured due

|  to different clocks in different proxies. Then, what is suggested in
section 5.2.2,

|  rule 6, is that "The receiver SHOULD store the peer-related timing
information

|  [.] separately for each different proxy (which can be identified by the
different

|  Key Hash values of the proxied message) and separately from the timing

|  information associated to the IP of node for which the message is
proxied".

|  

|  Maybe in section 6.2, a reference to section 5.2.2, rule 6 could be
added, so this

|  issue would be clarified.

|  

 

Done

 

|  

|  |  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.

|  

|  

|  Yes, this sentence implicitly assumes that there may be unsecured
messages,

|  which is not the style of the rest of the document, and only appears
clearly in

|  section 7.

|  

|  I think it would be best to reword it so that it does not suggest yet the
possibility

|  of unsecured messages.

|  

 

Done

 

|  

|  |

|  |  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?

|  

|  

|  The key word of this paragraph (the third) is 'originated', while in the
first

|  paragraph of section 7.1 the key word is 'received'. What this is saying
is that a

|  proxy can secure a message generated either in a RFC3971 or SPND node,
since

|  regarding to the rules of generating ND messages, both behave exactly the
same

|  (the difference is in the receiving rules for PS options).

|  

|  I can clarify a bit this differences

|  

 

Added "(note that the difference between RFC3971 nodes and SPND nodes only
affect to the ability to process received NDP messages containing a PS
option, not in the way they generate messages secured by SEND)" at the end
of the paragraph.

 

  

|  

|  |

|  |  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.

|  

|  This is related with the acceptance of secured/unsecured message, and as

|  discussed above, should be clarified, starting in section 5.

|  

|  |  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 doesn't seem to
mean

|  |  the same as "locally generated" elsewhere.

|  

|  Yes, you are right, this is imprecise. In this case "generate" means both

|  'forwarding' and 'synthesizing'. This should be clarified.

  

Done

  

|  |  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

|  This is not addressed in this document. I have commented about this above
in

|  this email, in a paragraph starting by "Well, I think this is specific to
each

|  deployment scenario [.]"

|  

|  |  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?

|  

|  Yes, this is true. Of course this could optimize SPND operation.

|  

|  However, this may or may not be reasonable, depending on the scenario and

|  particular configuration. For example, for PMIPv6, the proxy only
performs its

|  function for the MAG, not for any host, so it is not evident that the
proxy knows if

|  a node is SPND or not. For MIPv6, the proxy may or may not know the SPND
or

|  not (maybe, it knows when the node moves away, by accessing to some

|  database, but not if the node is in the link.)

|  

|  I feel that this is too related with optimization, that should not be
included in the

|  document. Another option is to include a MAY statement in section 7
commenting

|  this possibility, in a generic way, just for the sake of completeness.
What do you

|  think?

|  

|  

|  |  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.

|  

|  Yes, I'm really convinced. I will

|  

|  

|  |

|  |      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?

|  

|  Yes it is, for example for the RFC4389 case

|  

|  |  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.

|  

|  Yes. I include the PS option here.

|  

 

The following text has been included:

"For scenarios in which ND messages are translated for nodes that

      can arrive to the link in which the proxy operates, the rule can

      be easily applied: only for messages validated in the Secure ND

      Proxy according to the SEND specification [RFC3971], or according

      to Section 5.2.2 of this specification for messages containing a

      PS option (which means that another proxy previously checked that

      the original message was secured) [.]"

 

|  |  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

|  |  option.

|  

|  Yes, that's the reason why. I will include a text similar to this to
explain.

|  

 

I have substituted the cited text with this:

"   A compromised Secure ND Proxy provisioned with an authorization

   certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is

   able, like a compromised router to siphon off traffic from the host,

   or mount a man-in-the-middle attack, for hosts communicating to off-

   link hosts.  A compromised Secure ND Proxy provisioned with an

   authorization certificate with a KeyPurposeId value of id-kp-

   sendProxiedOwner can siphon off traffic or mount a man-in-the-middle

   attack for communication between on-link hosts, even if the hosts use

   SEND.  Note that different application scenarios may require one type

   of authorization, the other, or both.  To minimize security risks,

   authorization capabilities SHOULD NOT exceed the ones strictly

   required by the application scenario to be deployed."

 

 

|  

|  |

|  |      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 I'm not sure.

|  

|  Yes, yours is a more accurate wording. I include, thanks

|  

Done

 

|  

|  |      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.  I'm 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?

|  

|  

|  [I-D.ietf-csi-sndp-prob] is in AUTH48 status, so. I assume it will
progress.

|  I agree that some hints should be included in draft-ietf-csi-proxy-send,
and also

|  indicating how the particular way Timestamp is handled here affects to
security.

|  Then, I suggest substituting the text you cited with the text below.

|  

|  I also think the detail (and credit) of the problem statement could be
that of [I-

|  D.ietf-csi-sndp-prob], so I end the paragraph referring to it, and I'm
not

|  explaining completely its text.

|  

|  Do you think this is ok?

|  

|  "Protection against reply attacks from unsolicited messages such as
Neighbor

|  Advertisements, Router Advertisements, and Redirects is provided by the
use of

|  the Timestamp option. When Secure ND Proxy is used, each proxy and the
host

|  for which a proxy acts on behalf are considered to be different peers in
terms of

|  Timestamp verification. Since the information provided by the host and a
proxy

|  maybe different, including different link-layer addresses, a reply attack
could

|  affect the operation of a third node: replying messages issued by a host
that is

|  no longer in the link can prevent the use of a proxy, and replying
messages of a

|  proxy when the host is back in the link can prevent the access to the
host. This

|  kind of attacks can be performed until the timestamp of the peer (either
the host

|  or a proxy) is no longer valid for the receiver. The window of
vulnerability is in

|  general larger for the first message received from a new peer than for

|  subsequent messages received from the same peer (see RFC3971). A more

|  detailed analysis of the possible attacks is described in section 7.3 of
[I-D.ietf-csi-

|  sndp-prob]."

|  

 

Included

 

|  

|  |

 

The rest of the email referred to NITS, which I have changed.

 

Regards,

Alberto