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

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

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.

 

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

 

 

[PART DISCUSSED IN OTHER EMAIL]

 

 

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

 

|  

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

 

|  

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

 

|  

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

 

 

|  

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

 

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.

 

 

|  

|  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

 

|  

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

 

|  

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

 

|  

|  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

 

|  

|  

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

 

|  

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

 

|  

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

 

|  

|      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

 

|  

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

 

|  

|  

|  

|  

|  NITS

|  

|  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

|                                            ^^^^^^^^

|                                            securely

Ok

 

|  

|  Sec 6.1 p 13-14

|  

|  Sometimes the Home Address is abbreviated HoA and sometimes as HA

 

I have reviewed, and I think this section is correct: I find two places in
which 'HA' is used as an address, being the 'Home Agent address' (different
use from the 'box' 'Home Agent'):

- HA_LL, which is the Link Layer of the Home Agent

- In Figure 2, 'SRC = HA', which is correct since the it is the IP address
of the HA (and not the HoA) the one used for this, as stated in RFC3775

 

 

|  

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

|                   ^^^^^^

|                   attaches

ok

 

|  

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

 

Ok

 

|  

|  

|  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

|            link

|  

|  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

ok

 

|  

|  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

|           ^^

|           as

|      message received by a non-SEND host or RFC3971 host is the same of an

|                                                                      ^^

|                                                                      as

|      unsecured ND message.

ok

 

|  

|  Sec 8 p 22

|  

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

|              ^^

|              on.

 

Ok (although this may change, as commented above).

 

 

Thanks again for your review!! 

I really appreciate your contribution.

 

Alberto