Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

From: [email-masked]
Date: Tue, 23 Apr 2013 10:36:42 -0400

(sorry if you receive duplicate of this message. Some of my mails to 
the mailing list are rejected, and I'm trying to figure out with our 
secretary...)

Hi,

I had a review of the draft. I think it's in good shape, and ready for 
WGLC.

a few comments:

In section 6 & 7, I didn't find the definition of notation
	<foo>+
Not in this draft, either rfc 5444.

page 13,  source code address ==> source node address?

section 9.1 bullet 1 states that the <msg-hop-limit> and 
<msg-hop-count> must be zeroed before calculating ICV. I'm thinking 
about that we might need to mention that some protocol-specific mutable 
fields must be zeroed here also. For example, in LOADng, as a reactive 
protocol, metric fields are defined as "mutable" (in the meantime, I 
still have some thoughts on those mutable fields that I need to discuss 
with other LOADng authors, but it's not that relevant here).

best

Jiazi

On Apr 15, 2013, at 5:59 PM, [email-masked] wrote:

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group 
of the IETF.

	Title           : Integrity Check Value and Timestamp TLV Definitions 
for Mobile Ad Hoc Networks (MANETs)
	Author(s)       : Ulrich Herberg
                         Thomas Heide Clausen
                         Christopher Dearlove
	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
	Pages           : 24
	Date            : 2013-04-15

Abstract:
  This document revises, extends and replaces RFC 6622.  It describes
  general and flexible TLVs for representing cryptographic Integrity
  Check Values (ICVs) and timestamps, using the generalized Mobile Ad
  Hoc Network (MANET) packet/message format defined in RFC 5444.  It
  defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
  for affixing ICVs and timestamps to a packet, a message, and one or
  more addresses, respectively.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc6622-bis-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 24 Apr 2013 08:47:32 +0000

Jiazi

Thanks for that, I'll just comment on the one point where I disagree.

Putting some vague words in that protocols may indicate fields not to be covered is the sort of thing that I can predict will cause us problems at the IESG. And it's not really a good plan for a generic mechanism that can - at at present - be run independently of the routing protocol to acquire a protocol dependence. Rather I think that any routing protocols with a specific need to exclude data (which, all else being equal is a bad thing of course) should consider defining a new type extension - preferably one defined with some generic capability (could it, for example, list TLV types to be excluded?) But that's for the future. One thing I have learned is that design in advance of what might hypothetically be needed generally gets it wrong, so it would be good to wait until exactly what's needed is clear, and then define a new case.

Christopher

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 23 April 2013 15:37
To: [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi,

a few comments:

best

Jiazi

Abstract:

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Jiazi Yi <[email-masked]>
Date: Wed, 24 Apr 2013 12:54:22 +0200

Chris, 

I do understand your concern. We had this kind of discussion on mutable fields before, and this is something I'm still mulling over. 
The reason why I propose this for discussion is:

	- this rfc6622bis is for rfc5444, which is a general format for all manet protocols. 
	- The reactive protocol like LOADng does explicitly define such "mutable" fields. It is something at hand, not in the far future. 

In the meantime, I do agree that the necessity and how to take care of such mutable fields should be considered carefully. 
So I would agree that we keep the current rfc6622bis draft as it is for the moment, and I'll have more discussions with other LOADng authors on this. 

best 

Jiazi

---

From: Jiazi Yi <[email-masked]>
Date: Wed, 24 Apr 2013 18:12:20 +0200

Hi, 

After several mail exchange with some of the other authors, I think it would be better to keep the draft as it is on the mutable fields, because how to define/use protocol-specific mutable fields is not very clear at this point. 
If necessary, it would probably be better to put them in another document, after we figuring out exactly how to handle those fields. 

best

Jiazi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 24 Apr 2013 16:19:51 +0000

Thanks for that. I'm hoping we can proceed push out 6622bis, and the security document.

As a contribution to that future concept, I'll note that 6622(bis) is independent of the protocol. That I think is a desirable thing.

One idea (I'm not sold on it, it's just for consideration) is that if you are considering that, for example, you don't want to include a metric in your ICV, and that metric is in TLV type X (probably a full type with type extension, but that's another of those details) then as a new variant type extension ICV, you could add something to say "remove all TLVs with type extensions X, Y, Z before calculating ICV). Or maybe that needs to be a range. Or ... but first work out exactly what you want, then how it cleanly generalises (where a good generalisation is easier to implement than the special case).

-----Original Message-----
From: Jiazi Yi [mailto:[email-masked]] 
Sent: 24 April 2013 17:12
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

Hi, 

best

Jiazi

---

From: Jiazi Yi <[email-masked]>
Date: Wed, 24 Apr 2013 18:55:18 +0200

Thanks Chris for sharing your thought. 

Yes, those are all possibilities to consider. And a more fundamental issue I'm thinking about is the framework for securing re-active protocols, because it's much harder than pro-acitve ones. For example, do we want to require hop-by-hop authentication? Zeroing the metric field opens possible attack vector also... anyway, we can discuss this in other topics in the future. 

In the meantime, I reviewed the draft draft-ietf-manet-nhdp-olsrv2-sec-02, and I think it is fairly clear. I would support it for WGLC. 

Just one question:

In the draft:
=============
 The following constraints apply to these parameters:

   o  MAX_HELLO_TIMESTAMP_DIFF > 0

   o  MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL

   o  MAX_TC_TIMESTAMP_DIFF > 0

   o  MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME

   The second and fourth of those constraints assume ideal time
   synchronization of the clocks in all routers in the network. 
======================

My understanding is that, "the time difference equals 0" is for ideal time synchronization. So it should be The first and third assume ideal time synchronization? Or I missed something here? 

best

Jiazi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 25 Apr 2013 09:26:44 +0000

I think you missed something. Though there is a point we might have to consider that I'll get to.

These are constraints on your internal parameters. Let me just consider the HELLO ones, obviously the TC ones are similar.

The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the message appears to be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". Obviously that only makes sense for a positive age, hence the first constraint. That doesn't matter about synchronisation. It's actually a fairly obvious thing that almost doesn't need saying (but also see a bit later).

Now sticking for the moment to an assumption that we can measure the age of a packet/message, we want to bound how much slack we should allow. And that's the second constraint. (Right this moment I'm not sure why we picked REFRESH_INTERVAL rather than HELLO_INTERVAL, but it actually works either way.) But this is where synchronisation comes in (and why the_DIFF suffix). We measure the age by comparing our clock with the timestamp. If synchronised then that's the age, done.

If there's a synchronisation error, let's suppose we received at t2, it claims to be sent at t1, but (based on our clock) was actually sent at t1+e. So our test is

(t2 - t1) <= MAX_HELLO_TIMESTAMP_DIFF

but the age of the message, A is t2 - t1 - e, so

A <= MAX_HELLO_TIMESTAMP_DIFF - e

So if we want to only reject messages that are definitely too late, we need to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e (assume e is symmetrically distributed +ve and -ve. In turn this means that we should allow an extra margin of e on the constraint MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL.

Now the point of interest. What if we receive a message with an apparent negative age? If that's greater than the minimum value of e (or -e) that's fine. But more than that? Should we reject such messages?

-----Original Message-----
From: Jiazi Yi [mailto:[email-masked]] 
Sent: 24 April 2013 17:55
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

Just one question:

In the draft:
=============

best

Jiazi

---

From: Jiazi Yi <[email-masked]>
Date: Fri, 26 Apr 2013 14:10:41 +0200

Hi, 

> The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the message appears to be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". Obviously that only makes sense for a positive age, hence the first…

Yes. I agree. If we assume "network can be synchronized with sufficient precision", then the value can only be positive. 
Of course, if the network is not well synchronized, a negative is possible. 

> Now sticking for the moment to an assumption that we can measure the age of a packet/message, we want to bound how much slack we should allow. And that's the second constraint. (Right this moment I…

I'm just a little confused by why "assuming ideal time synchronization" is related to the constraints of 

	"MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL" 

I didn't quite get the relation here. 
What I understand is that, the "age" calculated by 

	local_router_time - HELLO_timestamp 

is only related to transmission delay of the message (if no attack happens).  When it is regarded "too old" (age > MAX_HELLO_TIMESTAMP_DIFF), it is discarded. 

> Now the point of interest. What if we receive a message with an apparent negative age? If that's greater than the minimum value of e (or -e) that's fine. But more than that? Should we reject such m…

Apparently, if the network is not synchronized, a negative age can happen. What I understand is that, this document won't take care of synchronization and related error? Because those would be another big problem to deal with...

best

Jiazi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Apr 2013 12:21:38 +0000

>	"MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL" 

I'm going to do the TC example:

MAX_TC_TIMESTAMP_DIFF < TC_INTERVAL

just so I can get some easier numbers to play with. But the essentials are the same.

Now let's suppose TC_INTERVAL is 5 seconds, and it takes a maximum time of 2 seconds for a message to propagate across the network. So we could in principle in this case discard any message that arrives more than 2 seconds late. so we could set MAX_TC_TIMESTAMP_DIFF to 2 seconds if we had perfect timings.

Now let's consider that our clocks might be adrift by 2 seconds. Now consider what MAX_TC_TIMESTAMP_DIFF is: it's the parameter you use to compare your time measurement, and the timestamp in the message. It's a practical parameter, one you use in that way, not an abstract parameter. So now a perfectly good TC message might arrive with a timestamp 2 seconds early (by our reckoning) and having travelled for up to 2 seconds. So the practical parameter we need, MAX_TC_TIMESTAMP_DIFF is 4 seconds.

---

From: Jiazi Yi <[email-masked]>
Date: Fri, 26 Apr 2013 14:47:40 +0200

Hi,

> Now let's suppose TC_INTERVAL is 5 seconds, and it takes a maximum time of 2 seconds for a message to propagate across the network. So we could in principle in this case discard any message that ar…

Yes. I fully agree (btw, in the draft, it's T_HOLD_TIME? I think TC_INTERVAL makes more sense). 
But according to the draft, if we had perfect timings, it is set to T_HOLD_TIME (or TC_INTERVAL)?

=========
The second and fourth (MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME) of those constraints assume ideal time
   synchronization of the clocks in all routers in the network.
=======

Of course, it can be set to T_HOLD_TIME, because it's actually a looser constraint. 
My only problem is, there is no direct relationship between perfect timing, and setting the value to T_HOLDE_TIME (for TC). Maybe I'm too nit-picking here? :-P

> Now let's consider that our clocks might be adrift by 2 seconds. Now consider what MAX_TC_TIMESTAMP_DIFF is: it's the parameter you use to compare your time measurement, and the timestamp in the me…

Yes, and I have no problem with this. 

Jiazi

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Apr 2013 14:55:25 +0200

On 04/26/2013 02:47 PM, Jiazi Yi wrote:
>> Jiazi:
>>> I'm just a little confused by why "assuming ideal time
>>> synchronization" is related to the constraints of
>>>
>> Now let's suppose TC_INTERVAL is 5 seconds, and it takes a maximum
>> time of 2 seconds for a message to propagate across the network. So
>> we could in principle in this case discard any message that arrives
>> more than 2 seconds late. so we could set MAX_TC_TIMESTAMP_DIFF to
>> 2 seconds if we had perfect timings.
>
> Yes. I fully agree (btw, in the draft, it's T_HOLD_TIME? I think
> TC_INTERVAL makes more sense). But according to the draft, if we had
> perfect timings, it is set to T_HOLD_TIME (or TC_INTERVAL)?
>
> ========= The second and fourth (MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME)
> of those constraints assume ideal time synchronization of the clocks
> in all routers in the network. =======
>
> Of course, it can be set to T_HOLD_TIME, because it's actually a
> looser constraint. My only problem is, there is no direct
> relationship between perfect timing, and setting the value to
> T_HOLDE_TIME (for TC). Maybe I'm too nit-picking here? :-P

TCs also can get lost... so the maximum acceptable time-difference 
should be TC_VALIDITY_TIME.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Apr 2013 13:19:03 +0000

I don't see anything that support your comment that according to the draft, if we had perfect timings, it is set to T_HOLD_TIME. What makes you say that?

-----Original Message-----
From: Jiazi Yi [mailto:[email-masked]] 
Sent: 26 April 2013 13:48
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

Hi,

=========

Jiazi

---

From: Jiazi Yi <[email-masked]>
Date: Fri, 26 Apr 2013 15:23:46 +0200

> TCs also can get lost... so the maximum acceptable time-difference should be TC_VALIDITY_TIME.

I'm not sure we are talking about the same time-difference?

The acceptable time-difference between two consecutive TC messages is T_HOLD_TIME (the  TC_VALIDITY_TIME you mentioned, to update the information base). 

However, in this case, it's more the time-difference between *the* TC message is sent out, and *the* message is received (with or without sync)?

Jiazi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Apr 2013 13:43:10 +0000

T_HOLD_TIME is what you've described as TC_VALIDITY_TIME.

But I'm not convinced, because this is about message replay, not message loss. What I am convinced of is that REFRESH_TIME and T_HOLD_TIME are not a matched pair.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 26 April 2013 13:55
To: [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Apr 2013 13:46:02 +0000

Which means that we don't have something perfect to compare it with. But these are indicative figures - they are inequalities - so in fact either TC_INTERVAL or T_HOLD_TIME would work, it's just a matter of which is clearer. I think the better answer is TC_INTERVAL, but with a comment about being significantly smaller.

(It's a strange ad hoc network that sends messages more often than they propagate across it.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiazi Yi
Sent: 26 April 2013 14:24
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

Jiazi

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 26 Apr 2013 15:28:34 +0100

I agree with you, the document should state synchronization issues/concerns,

AB

On Fri, Apr 26, 2013 at 1:10 PM, Jiazi Yi <[email-masked]> wrote:

> > These are constraints on your internal parameters. Let me just consider
> the HELLO ones, obviously the TC ones are similar.
> >
> > The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the message appears to
> be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". Obviously that only
> makes sense for a positive age, hence the first constraint. That doesn't
> matter about synchronisation. It's actually a fairly obvious thing that
> almost doesn't need saying (but also see a bit later).
>
> Yes. I agree. If we assume "network can be synchronized with sufficient
> precision", then the value can only be positive.
> > Now sticking for the moment to an assumption that we can measure the age
> of a packet/message, we want to bound how much slack we should allow. And
> that's the second constraint. (Right this moment I'm not sure why we picked
> REFRESH_INTERVAL rather than HELLO_INTERVAL, but it actually works either
> way.) But this is where synchronisation comes in (and why the_DIFF suffix).
> We measure the age by comparing our clock with the timestamp. If
> synchronised then that's the age, done.
>
>
> is only related to transmission delay of the message (if no attack
> happens).  When it is regarded "too old" (age > MAX_HELLO_TIMESTAMP_DIFF),
> it is discarded.
>
>
> >
> > If there's a synchronisation error, let's suppose we received at t2, it
> claims to be sent at t1, but (based on our clock) was actually sent at
> t1+e. So our test is
> >
> > So if we want to only reject messages that are definitely too late, we
> need to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e (assume
> e is symmetrically distributed +ve and -ve. In turn this means that we
> should allow an extra margin of e on the constraint
> MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL.
> >
> > Now the point of interest. What if we receive a message with an apparent
> negative age? If that's greater than the minimum value of e (or -e) that's
> fine. But more than that? Should we reject such messages?
>
> Apparently, if the network is not synchronized, a negative age can happen.
> What I understand is that, this document won't take care of synchronization
> and related error? Because those would be another big problem to deal
> with...
>
> best
>
> Jiazi
>
> >
> > --
> > Christopher Dearlove
> > Yes, those are all possibilities to consider. And a more fundamental
> issue I'm thinking about is the framework for securing re-active protocols,
> because it's much harder than pro-acitve ones. For example, do we want to
> require hop-by-hop authentication? Zeroing the metric field opens possible
> attack vector also... anyway, we can discuss this in other topics in the
> future.
> >
> > In the meantime, I reviewed the draft
> draft-ietf-manet-nhdp-olsrv2-sec-02, and I think it is fairly clear. I
> would support it for WGLC.
> >
> > Just one question:
> >
> > In the draft:
> > =============
> > My understanding is that, "the time difference equals 0" is for ideal
> time synchronization. So it should be The first and third assume ideal time
> synchronization? Or I missed something here?
> >
> > best
> >
> > Jiazi
> >
> >> As a contribution to that future concept, I'll note that 6622(bis) is
> independent of the protocol. That I think is a desirable thing.
> >>
> >> One idea (I'm not sold on it, it's just for consideration) is that if
> you are considering that, for example, you don't want to include a metric
> in your ICV, and that metric is in TLV type X (probably a full type with
> type extension, but that's another of those details) then as a new variant
> type extension ICV, you could add something to say "remove all TLVs with
> type extensions X, Y, Z before calculating ICV). Or maybe that needs to be
> a range. Or ... but first work out exactly what you want, then how it
> cleanly generalises (where a good generalisation is easier to implement
> than the special case).
> >>
> >> --
> >> Christopher Dearlove
> >> After several mail exchange with some of the other authors, I think it
> would be better to keep the draft as it is on the mutable fields, because
> how to define/use protocol-specific mutable fields is not very clear at
> this point.
> >> If necessary, it would probably be better to put them in another
> document, after we figuring out exactly how to handle those fields.
> >>
> >> best
> >>
> >> Jiazi
> >>
> >>> I do understand your concern. We had this kind of discussion on
> mutable fields before, and this is something I'm still mulling over.
> >>>     - The reactive protocol like LOADng does explicitly define such
> "mutable" fields. It is something at hand, not in the far future.
> >>>
> >>> In the meantime, I do agree that the necessity and how to take care of
> such mutable fields should be considered carefully.
> >>> So I would agree that we keep the current rfc6622bis draft as it is
> for the moment, and I'll have more discussions with other LOADng authors on
> this.
> >>>
> >>> best
> >>>
> >>> Jiazi
> >>>
> >>>> Putting some vague words in that protocols may indicate fields not to
> be covered is the sort of thing that I can predict will cause us problems
> at the IESG. And it's not really a good plan for a generic mechanism that
> can - at at present - be run independently of the routing protocol to
> acquire a protocol dependence. Rather I think that any routing protocols
> with a specific need to exclude data (which, all else being equal is a bad
> thing of course) should consider defining a new type extension - preferably
> one defined with some generic capability (could it, for example, list TLV
> types to be excluded?) But that's for the future. One thing I have learned
> is that design in advance of what might hypothetically be needed generally
> gets it wrong, so it would be good to wait until exactly what's needed is
> clear, and then define a new case.
> >>>>
> >>>> Christopher
> >>>>
> >>>> --
> >>>> Christopher Dearlove

---

From: Jiazi Yi <[email-masked]>
Date: Fri, 26 Apr 2013 16:39:50 +0200

I didn't say that this document should state sync issues. 
This document assumes that clock is synchronised. How to synchronise would be out the scope of this document. 

best

Jiazi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Apr 2013 14:40:25 +0000

I don't believe that is what Jiazi said. Furthermore the document already discusses synchronization issues, from the need to relax constraints if synchronisation is not possible, to a note in the Limitations section about what to do if synchronisation is not possible.

The actual nit here is nothing to do with synchronisation issues, but which parameters to use as suggested bounds when synchronisation is ideal. I think the choice should be between (a) HELLO_INTERVAL and TC_INTERVAL, and (b) H_HOLD_TIME and T_HOLD_TIME. In case (a) we should drop the "significantly less" caveat. Note that what we are actually saying is that the parameter is greater than is how long the message might take to arrive, but we don't have that, we just have the indicated parameters. (A sophisticated implementation could choose to use the sender's versions of these read from INTERVAL_TIME and VALIDITY_TIME TLVs. But really, as this is guidance, it's not critical.)

Preferences: (a) or (b)? - We can put this in with other nits found.

[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: 26 April 2013 15:29
To: Jiazi Yi
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf> on how to deal with suspicious emails.
I agree with you, the document should state synchronization issues/concerns,

AB

On Fri, Apr 26, 2013 at 1:10 PM, Jiazi Yi <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

best

Jiazi

> Tel: +44 1245 242194<tel:%2B44%201245%20242194> |  Fax: +44 1245 242124<tel:%2B44%201245%20242124>
> [email-masked]<mailto:[email-masked]> | http://www.baesystems.com
>
> From: Jiazi Yi [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>
> On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Tel: +44 1245 242194<tel:%2B44%201245%20242194> |  Fax: +44 1245 242124<tel:%2B44%201245%20242124>
>> [email-masked]<mailto:[email-masked]> | http://www.baesystems.com
>>
>> From: Jiazi Yi [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: [email-masked]<mailto:[email-masked]>
>> On Apr 24, 2013, at 12:54 PM, Jiazi Yi <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>> Chris,
>>>
>>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)" <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>> Jiazi
>>>>
>>>> Tel: +44 1245 242194<tel:%2B44%201245%20242194> |  Fax: +44 1245 242124<tel:%2B44%201245%20242124>
>>>> [email-masked]<mailto:[email-masked]> | http://www.baesystems.com
>>>>
>>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
>>>> To: [email-masked]<mailto:[email-masked]>
>>>> On Apr 15, 2013, at 5:59 PM, [email-masked]<mailto:[email-masked]> wrote:
>>>>
>>>>
>>>> [email-masked]<mailto:[email-masked]>
>>>> [email-masked]<mailto:[email-masked]>

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 26 Apr 2013 15:46:56 +0100

In MANET practice nothing is ideal, maybe can be assumed in fixed wireless
networks. I mean to state; does the document suggest parameters for
non-synchronised network = practical manet.

AB

On Fri, Apr 26, 2013 at 3:40 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

>  I don't believe that is what Jiazi said. Furthermore the document
> already discusses synchronization issues, from the need to relax
> constraints if synchronisation is not possible, to a note in the
> Limitations section about what to do if synchronisation is not possible.**
> **
>
> ** **
>
> The actual nit here is nothing to do with synchronisation issues, but
> which parameters to use as suggested bounds when synchronisation is ideal.
> I think the choice should be between (a) HELLO_INTERVAL and TC_INTERVAL,
> and (b) H_HOLD_TIME and T_HOLD_TIME. In case (a) we should drop the
> "significantly less" caveat. Note that what we are actually saying is that
> the parameter is greater than is how long the message might take to arrive,
> but we don't have that, we just have the indicated parameters. (A
> sophisticated implementation could choose to use the sender's versions of
> these read from INTERVAL_TIME and VALIDITY_TIME TLVs. But really, as this
> is guidance, it's not critical.)****
>
> ** **
>
> Preferences: (a) or (b)? - We can put this in with other nits found.****
>
> ** **
>
> -- ****
>
> Christopher Dearlove****
>
> Tel: +44 1245 242194 |  Fax: +44 1245 242124****
>
> Registered in England & Wales No: 1996687****
>
> ** **
>
> *From:* Abdussalam Baryun [mailto:[email-masked]]
> *Sent:* 26 April 2013 15:29
> *To:* Jiazi Yi
> *Cc:* Dearlove, Christopher (UK); [email-masked]
>
> *Subject:* Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt****
>
> ** **
>
> ** **
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.***
> *
>
> Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>on how to deal with suspicious emails.
> *****
>
>   I agree with you, the document should state synchronization
> issues/concerns,****
>
>  ****
>
> AB****
>
> ** **
>
> On Fri, Apr 26, 2013 at 1:10 PM, Jiazi Yi <[email-masked]> wrote:****
>
> Hi,****
>
>
> almost doesn't need saying (but also see a bit later).****
>
> ****
> ****
> it is discarded.****
> fine. But more than that? Should we reject such messages?****
>
> Jiazi****
> https://www.ietf.org/mailman/listinfo/manet****
>
> ** **
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Apr 2013 14:49:58 +0000

You have read it, right? So you've read the section where it discusses what happens in a non-synchronised network. 9.2 if you want a hint.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 26 April 2013 15:47
To: Dearlove, Christopher (UK)
Cc: [email-masked]; Jiazi Yi
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf> on how to deal with suspicious emails.
In MANET practice nothing is ideal, maybe can be assumed in fixed wireless networks. I mean to state; does the document suggest parameters for non-synchronised network = practical manet.

AB

On Fri, Apr 26, 2013 at 3:40 PM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
I don't believe that is what Jiazi said. Furthermore the document already discusses synchronization issues, from the need to relax constraints if synchronisation is not possible, to a note in the Limitations section about what to do if synchronisation is not possible.

From: Abdussalam Baryun [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 26 April 2013 15:29
To: Jiazi Yi
Cc: Dearlove, Christopher (UK); [email-masked]<mailto:[email-masked]>

*** WARNING ***

AB

best

Jiazi

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 27 Apr 2013 08:08:29 +0200

Hi Chris,

I am trying to understand the document and sorry if confused. IMO the
document assuming synchronised clocks of routers for integrity check,
my comments below,

On Fri, Apr 26, 2013 at 3:49 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

>  You have read it, right? So you've read the section where it discusses
>  what happens in a non-synchronised network. 9.2 if you want a hint.****

I didnot do my final read but yes read through 6622-bis, sorry if
confused, but interested to discuss the issue mentioned by Jiazi,

Do you mean section 9.2 of the 6622-bis I-D or section 9.2 of
nhdp-olsrv2-sec-01 I-D, the second I-D is refering to the 6622-bis
that it uses sequence number, but not finding that in the subject I-D
or 6622-bis-02.

nhdp-olsrv2-sec> If no synchronized clocks are available in the MANET,
replay attacks cannot be countered by the framework provided by this
document.  An
   alternative version of the TIMESTAMP TLV defined in [RFC6622bis],
   with a monotonic sequence number, may have some partial value in this
   case, but will necessitate adding state to record observed message
   sequence number information.

AB> is there consideration of errors in time value among clocks in
seconds that may affect functions?

AB>does the document suggest integrity parameters/issues for
non-synchronised network = practical manet?

I dont find the parameter of *monotonic sequencing number* into
6622-bis for non-synchronised clocks for integrity, but refered by
another I-D, which not clear for me.

Best regards

AB

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If authors think that this message is not correct and I need more
reading you may ignore and I will understand, so I will put my review
comments after final review. This message is a discussion of reviewing
parts of the documents (trying to understand)or reply to other
participant discussion/comments on synchronisation issues.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++