Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-03

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

Hi,

|  -----Mensaje original-----
|  De: Tony Cheneau [mailto:[e-mail]]
|  Enviado el: viernes, 09 de abril de 2010 16:33
|  Para: [e-mail]
|  CC: [e-mail]
|  Asunto: Comments on draft-ietf-csi-proxy-send-03
|  
|  Hello,
|  
|  I read your draft and some comments.
|  
|  I will start with the "editorial" ones:
|  - I often read "PSO option", which expends to "Proxy Signature Option
|     option". IMHO, "PS option" would be better.
|  - Section 6.2: "acccording to" => "according to"
|  - Section 7.2: "these node interpret" => "these nodeS interpret"

ok

|  
|  
|  One technical comment/question:
|  - Section 6.2
|  "  When a MAG replies to a RS with a RA, the source address MUST be
|      equal to the MAG link-local address associated to the MN in this
|      PMIPv6 domain and its own link layer address as Source link-layer
|      address.  Then a timestamp (generated by the proxy) and nonce (if
|      appropriate, acccording to [RFC3971]), MUST be included.  Finally, a
|      PSO option signing the message MUST be included as the last option of
|      the message.  This procedure is followed for any other ND message
|      that could be generated by the MAG to a MN. "
|  I understand from PMIP that the node that moves through the domain sees
|  only one Link-Local address for all the MAGs. From your SNDP proposal,
|  the node relies on the RFC 3971 rules to process the timestamp. I mean,
|  the node could implement the mechanism proposed as a SHOULD in Section
|  5.3.4.2 of RFC 3971. Here, my concern is that the node will most likely
|  consider the NDP messages of all the other MAG (after the first one it
|  met) as replayed packets.
|  
|  A small example, two MAGs, MAG_A and MAG_B. MAG_B's clock has minus one
|  minute difference with MAG_A.  MAG_A sends a RA message secured with a
|  PSO. The nodes verifies it and record a RDlast and TSlast value (as per
|  RFC 3971). The node moves and MAG_B sends a RA message.  The node read
|  the Timestamp option and compares it with its RDlast and TSlast value.
|  The message is rejected as it looks like a replayed message.

Yes, I see the problem, good point.
This may also occur for MIPv6 when a node switches from communicating with
the MN to the Secure Proxy ND, and viceversa.

I think the solution is to assume that timestamp checking must be performed
independently for the different possible sources (the MN, the Secure Proxy
ND, the MAG), i.e. process the timestamp of a message received for the first
time from a proxy as if it were the first message of a communication.
Therefore, I would replace rule 5 in 5.2.2 of draft-ietf-csi-proxy-send-03
with two rules (which separate timestamp and nonce for the sake of clarity):

"5. The Timestamp option MUST be processed as specified in
       [RFC3971] Section 5.3.4, except for replacing 'RSA Signature
       option' by 'PS option'. The receiver SHOULD store the peer-related
timing information specified in [RFC3971] Section 5.3.4.1 and 5.3.4.2
(RDlast, TSlast) 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. In this way, a message received for the first
time from a proxy (i.e. for which there is no information stored in the
cache) SHOULD be checked as messages received from new peers (as in
[RFC3971] section 5.3.4.2).

6. The Nonce option MUST be processed as specified in 
       [RFC3971] Section 5.3.4, except for replacing 'RSA Signature
       option' by 'PS option'. "
[...]"

I think it is not necessary to say that if the message is later received
from the original host (not from the proxy), the Timestamp is checked with
the time values specific to the host (not with the values specific to the
proxy).

I think this does not introduce new security considerations: on one hand,
caches from previous sending nodes communicating don't need to be deleted,
so old messages cannot be replied; and on the other hand, security
considerations on RFC 3971 section 9.2.5 apply to the messages sent for the
first time from the proxies.

What do you think? 

|  
|  Or maybe I missed the part that says the clocks are implicitly
|  synchronised (or something else) ? Either way, could you clarify the
|  situation for me and maybe add some text in the draft about this ?

I hope the previous solution is cleaner than requiring synchronization.

|  
|  Apart from the minor points I noted, the overall document is in a very
good
|  shape.
|  
|  (Also, sorry for my late reply to this WGLC)
|  
|  Hope it helps.

Sure, thanks Tony

Alberto

|  
|  Regards,
|   	Tony