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

From: Tony Cheneau <[email-masked]>
Date: Fri, 9 Apr 2010 16:33:21 +0200 (CEST)

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"

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.

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 ?

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.

Regards,
 	Tony

---

From: Alberto García <[email-masked]>
Date: Fri, 9 Apr 2010 18:36:59 +0200

Hi,

|  -----Mensaje original-----
|  De: Tony Cheneau [mailto:[email-masked]]
|  Enviado el: viernes, 09 de abril de 2010 16:33
|  Para: [email-masked]
|  CC: [email-masked]
|  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

---

From: Tony Cheneau <[email-masked]>
Date: Sat, 10 Apr 2010 00:05:36 +0200 (CEST)

Hello Alberto,

Answers inline.

On Fri, 9 Apr 2010, Alberto García wrote:

[...]

> first time from the proxies.
I think this is OK (the wording and the solution). IMHO, having separate
(RDlast, TSlast) for each entity (be it proxy or proxied node) is the
right thing to do.

I also do not see any new security concerns here.

> I hope the previous solution is cleaner than requiring synchronization.
Yes, way cleaner. :)

Regards,
 	Tony

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 9 Apr 2010 15:51:19 -0700

Tony,

Thanks for reviewing the draft. I'm following up on the timestamp issues you're pointing at below.

> situation for me and maybe add some text in the draft about this ?

PMIPv6 relies to a large extent on the use of Timestamps in Proxy Binding Updates. AFAIK there are no potential use of PMIPv6 that relies on sequence numbers for PBU re-ordering. When PMIPv6 use timestamps, the clocks on the MAGs have to be synchronized.

In addition, I am also unsure that there is a practical problem. The timestamp is only used for verifications of unsolicited messages. Since unsolicited router advertisements are only send periodically, it seems to me that they will not be sent often enough for the issue you describe to occur.

( and even my phone runs NTP today :)

--julien

---

From: Alberto García <[email-masked]>
Date: Mon, 12 Apr 2010 11:45:28 +0200

Hi

|  -----Mensaje original-----
|  De: Laganier, Julien [mailto:[email-masked]]
|  Enviado el: sábado, 10 de abril de 2010 0:51
|  Para: Tony Cheneau; [email-masked]
|  CC: [email-masked]
|  Asunto: RE: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-03
|  
|  Tony,
|  
|  Thanks for reviewing the draft. I'm following up on the timestamp issues
you're
|  pointing at below.
|  
|  Tony Cheneau wrote:
|  >
|  > [...]
|  >
|  > 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.
|  >
|  > 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 ?
|  
|  PMIPv6 relies to a large extent on the use of Timestamps in Proxy Binding
|  Updates. AFAIK there are no potential use of PMIPv6 that relies on
sequence
|  numbers for PBU re-ordering. When PMIPv6 use timestamps, the clocks on
the
|  MAGs have to be synchronized.
|  
|  In addition, I am also unsure that there is a practical problem. The
timestamp is
|  only used for verifications of unsolicited messages. Since unsolicited
router
|  advertisements are only send periodically, it seems to me that they will
not be
|  sent often enough for the issue you describe to occur.

Yes, although in any case I think it is still a good approach to state that
timestamps are only meaningful when coming from the same source, as stated
before. 
Secure Proxy ND could be used for other scenarios in which problems may
arise.

Regards,
Alberto

|  
|  ( and even my phone runs NTP today :)
|  
|  --julien