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

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

Hi

|  -----Mensaje original-----
|  De: Laganier, Julien [mailto:[e-mail]]
|  Enviado el: sábado, 10 de abril de 2010 0:51
|  Para: Tony Cheneau; [e-mail]
|  CC: [e-mail]
|  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