Subject: [netlmm] Other IETF protocols and time dependency

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Sep 2007 12:13:21 +0200

Following my quest on what and how other IETF protocols depend on time, 
here's my current list; there may be errors.

Timestamps in messages
----------------------
Mobile IPv4 RFC3344
   -for security
   -requirement on entities be time synchronized

SeND Secure Neighbor Discovery RFC3971
   -for security
   -requirement on entities be time synchronized

SCTP Stream Control Transmission Protocol RFC2960
   -for security
   -no requirement on entities be time synchronized

RTP A Transport Protocol for Real-Time Applications RFC3550
   -for ordering
   -yes and no requirement on entities be time synchronized

No timestamps in messages
-------------------------
TCP RFC 793
ND Neighbor Discovery RFC 2461
ICMPv6 RFC 4443
BGP Border Gateway Protocol RFC4271
OSPF Open Shortest Path First RFC2328
Mobile IPv6 RFC3775
MOBIKE IKEv2 Mobility and Multihoming RFC4555
IKEv2 Internet Key Exchange RFC4306

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 14 Sep 2007 08:25:04 -0500

Alex,

You may need to add RFC3543 to the list. It is probably the most
relevant to the discussion.

On the other hand, I just would like to mention that when timestamp is
used for replay protection, message ordering is already guaranteed; for
FREE!

Regards,
Ahmad

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Friday, September 14, 2007 5:13 AM
> To: netlmm
> Subject: [netlmm] Other IETF protocols and time dependency
> 
> Following my quest on what and how other IETF protocols 
> depend on time, here's my current list; there may be errors.
> 
> Timestamps in messages
> ----------------------
> Mobile IPv4 RFC3344
>    -for security

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Sep 2007 15:48:00 +0200

> relevant to the discussion.

Right, that is "Registration Revocation in Mobile IPv4".
-for security
-no requirement on time synchronization between entities.

> On the other hand, I just would like to mention that when timestamp 
> is used for replay protection, message ordering is already 
> guaranteed; for FREE!

Hehe right :-)  If replay protection is provided then message ordering
is guaranteed too, for free.

But how?

If we provide replay protection (and implicitely message ordering) by
using timestamps then we need to write code to extend that P-BU with
timestamps encoding, and rely on time, etc etc.

If we provide replay protection with off-the-shelf IPsec (both IKEv2 and
ESP/AH do replay protection) then we can take advantage of MIP6
implementations doing it, of P-MIP6 already relying on IPsec and not
have to encode timestamp format.  All we'd have to do is link the IPsec
SA MAG-LMA to the MN's Home Address, a thing which was somehow already
done by rfc3776 and implementations of it.

It may be that using IPsec and not timestamps - for guaranteeing replay
protection and implicitly P-BU ordering - is more gratuitous.

Alex

> 
> Regards, Ahmad
> 
> 
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[email-masked]] Sent: Friday, September 14, 
>> 2007 5:13 AM To: netlmm Subject: [netlmm] Other IETF protocols and 
>> time dependency
>> 
>> Following my quest on what and how other IETF protocols depend on 
>> time, here's my current list; there may be errors.
>> 
>> Timestamps in messages ---------------------- Mobile IPv4 RFC3344 
>> -for security -requirement on entities be time synchronized
>> 
>> SeND Secure Neighbor Discovery RFC3971 -for security -requirement 
>> on entities be time synchronized
>> 
>> SCTP Stream Control Transmission Protocol RFC2960 -for security -no
>>  requirement on entities be time synchronized
>> 
>> RTP A Transport Protocol for Real-Time Applications RFC3550 -for 
>> ordering -yes and no requirement on entities be time synchronized
>> 
>> No timestamps in messages ------------------------- TCP RFC 793 ND 
>> Neighbor Discovery RFC 2461 ICMPv6 RFC 4443 BGP Border Gateway 
>> Protocol RFC4271 OSPF Open Shortest Path First RFC2328 Mobile IPv6 
>> RFC3775 MOBIKE IKEv2 Mobility and Multihoming RFC4555 IKEv2 
>> Internet Key Exchange RFC4306
>> 
>> Alex
>> 
>>  This email has been scanned by the MessageLabs Email Security 
>> System. For more information please visit 
>> http://www.messagelabs.com/email 
>> _______________________________________________ netlmm mailing list
>>  [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 14 Sep 2007 09:22:12 -0500

> Subject: Re: [netlmm] Other IETF protocols and time dependency
> 
> Ahmad Muhanna wrote:
> > Alex,
> > 
> > used for replay protection, message ordering is already guaranteed; 
> > for FREE!
> 
> Hehe right :-)  If replay protection is provided then message 
> ordering is guaranteed too, for free.
> 
> But how?
> 
> If we provide replay protection (and implicitely message 
> ordering) by using timestamps then we need to write code to 
> extend that P-BU with timestamps encoding, and rely on time, etc etc.
> 
> If we provide replay protection with off-the-shelf IPsec 
> (both IKEv2 and ESP/AH do replay protection) then we can take 
> advantage of MIP6 implementations doing it, of P-MIP6 already 
> relying on IPsec and not have to encode timestamp format.  
> All we'd have to do is link the IPsec SA MAG-LMA to the MN's 
> Home Address, a thing which was somehow already done by 
> rfc3776 and implementations of it.
> 
> It may be that using IPsec and not timestamps - for 
> guaranteeing replay protection and implicitly P-BU ordering - 
> is more gratuitous.
> 

[Ahmad]
Man. Listen, timestamp is not used for replay protection in MIP6. You
know that right!
The comment was related to MIP4 and probably to be more specific to your
own understanding of MIP4! :-)

On the other hand, you may continue your off-shelf prototyping in order
to judge how protocols out there works. Not a bad idea.

> >> SeND Secure Neighbor Discovery RFC3971 -for security 
> -requirement on 
> >> RFC3775 MOBIKE IKEv2 Mobility and Multihoming RFC4555 
> IKEv2 Internet 
> >> Key Exchange RFC4306
> >> 
> >> Alex
> >> 
> >> 
> _____________________________________________________________________
> >> _  This email has been scanned by the MessageLabs Email Security

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Sep 2007 16:31:01 +0200

> own understanding of MIP4! :-)

So what you want to say is that timestamps in PMIPv6 is not used for 
replay protection, but for message ordering, right?

What I'm saying is that if IPsec provides replay protection and 
implicitly message ordering then no need of timestamps, right? 
Especially since PMIPv6 does use IPsec.

> to judge how protocols out there works. Not a bad idea.

Thanks,

Alex