Subject: [manet] PacketBB-sec = WG Document?

From: Ian Chakeres <[email-masked]>
Date: Thu, 25 Mar 2010 14:40:54 -0400

During the MANET meeting Tuesday we discussed making PacketBB-sec (http://tools.ietf.org/id/draft-herberg-manet-packetbb-sec-03.txt) a WG document.

I would like to solicit comments on this document and making it a WG document. Please respond to me and/or the MANET list.

Thanks.
Ian Chakeres

---

From: Teco Boot <[email-masked]>
Date: Thu, 25 Mar 2010 21:43:43 +0100

I don't think we should work on solutions for security, 
before we have defined some targets. My personal opinion is 
that we need a standard for the basic stuff (signed 
packets, chain of trust). All the other would be experimental. 
Having flexible encoding is useful, but may also be a problem
by itself (incompatibility).

May I remind on the problem with packet sequence numbers. They are
optional in RFC5444, where other mechanisms depend on it (e.g. 
NHDP-LQ). Having the timestamp TLV enlarges the problem.

The term timestamp for something that may contain random numbers, 
sequential increments etc. seems not natural to me.

I am extremely worried on using Time Of Day in routing protocols.
Therefore, I am against accepting this document as WG document.
I see crashing routing protocols each day, because I set TOD 
each day, with the bad effect. I have to fix this one time, by better
TOD management. And kick out using TOD in the protocol used.

Regards, Teco

Op 25 mrt 2010, om 19:40 heeft Ian Chakeres het volgende geschreven:

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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 26 Mar 2010 00:39:41 +0100

> NHDP-LQ). Having the timestamp TLV enlarges the problem.

I'm afraid that I do not see that. Neither as a problem nor as  
something escalated by "timestamp TLVs". If you have a protocol or  
protocol extension, which requires "packet sequence numbers" to be  
present, then the specification of that protocol or protocol extension  
would mandate their inclusion. If RFC5444 rendered such a "packet  
sequence number" mandatory, then this would simply imply that all  
protocols - even those who would not need it - would be forced to  
carry extra octets over the channel.

Thomas

>> I would like to solicit comments on this document and making it a  
>> WG document. Please respond to me and/or the MANET list.
>>
>> Thanks.
>> Ian Chakeres

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Mar 2010 01:10:56 +0100

> by itself (incompatibility).
The advantage to have packetbb-sec as a working document is that there can be 
generic parser/generators for the format which support signing (and later 
encrypting). Adding this later to a parser can be a real pain. In my oppinion 
packetbb-sec does NOT offer security sollutions, it just defines a common 
format to handle signatures (and later maybe encryptions) of any kind.

Henning Rogge

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized

---

From: Teco Boot <[email-masked]>
Date: Fri, 26 Mar 2010 16:01:06 +0100

Thomas,

As a researcher, you are right.
I am involved in getting networks deployed, I have 
some experience how things work out. I think it is a bad 
idea to have 4 scenarios already with packet sequence numbers.
Aren't we building thinks far to complex?

By the way, the "nit" on packet sequence numbers is still in
nhdp-12. Forget to update? 

Regards, Teco

Op 26 mrt 2010, om 00:39 heeft Thomas Heide Clausen het volgende geschreven:

> I'm afraid that I do not see that. Neither as a problem nor as something escalated by "timestamp TLVs". If you have a protocol or protocol extension, which requires "packet sequence numbers" to be present, then the specification of that protocol or protocol extension would mandate their inclusion. If RFC5444 rendered such a "packet sequence number" mandatory, then this would simply imply that all protocols - even those who would not need it - would be forced to carry extra octets over the channel.
> 
> Thomas
>

---

From: Teco Boot <[email-masked]>
Date: Fri, 26 Mar 2010 16:10:02 +0100

Hi Henning,

By no means my intention was to stop working on code.
We should have running code before getting the standard out there.
And yes, maybe this code needs some updates during the process.
But because I prefer a clean procedure, I want first the objective,
then the proposals for implementation.
Charter says: "Routing security requirements and issues will also be
addressed." So we should look for a requirements document.

Regards, Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 29 Mar 2010 12:29:56 +0100

> nhdp-12. Forget to update? 

Can you remind us (well, me at least) what the nit was?

********************************************************************
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: Teco Boot <[email-masked]>
Date: Mon, 29 Mar 2010 14:36:16 +0200

RFC5444 says:
   o  The <pkt-seq-num> field, if present, contains a sequence number
      that is incremented by 1 for each packet generated by a node.  The
      sequence number after 65535 is 0.  In other words, the sequence
      number "wraps" in the usual way.

For nodes with multiple interfaces, the receiving nodes do not see all 
the packets, with bad results if this was assumed. Problems arise with
for example statistics (Ulrich his work) and link quality measurement
(NHDP, ETX-draft).

Regards, Teco

---

From: Henning Rogge <[email-masked]>
Date: Mon, 29 Mar 2010 14:41:31 +0200

> for example statistics (Ulrich his work) and link quality measurement
Packet-Sequence-Numbers should be interface specific. I think this might be one 
of the existing "bugs" in packetbb.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 29 Mar 2010 14:12:03 +0100

Yes. The problem is that this is a problem with RFC 5444,
not NHDP itself - at least in an ideal world.

Is the errata mechanism for RFCs appropriate here?

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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: Henning Rogge [mailto:[email-masked]] 
Sent: 29 March 2010 13:42
To: [email-masked]
Cc: Teco Boot; Dearlove, Christopher (UK); Thomas Heide Clausen
Subject: Re: [manet] PacketBB-sec = WG Document?

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Mon, 29 Mar 2010 15:54:11 +0200

This is an essential errata.
And not easy to refer to as Normative Reference.
You report it? Or shall I?
 
Teco.

---

From: Yannick Lacharité <[email-masked]>
Date: Mon, 29 Mar 2010 14:59:10 -0400

I am also in favor of making PacketBB-sec a WG document. On the specific
aspect of MANET security, I would also be in favor of bringing forth
documents that handle security issues that occur in the MANET; to tackle the
issues described within the Security Considerations' sections of drafts such
as OLSRv2, DYMO, NHDP and SMF.

-Yannick Lacharité

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ian Chakeres
Sent: March 25, 2010 2:41 PM
To: MANET IETF
Subject: [manet] PacketBB-sec = WG Document?

During the MANET meeting Tuesday we discussed making PacketBB-sec
(http://tools.ietf.org/id/draft-herberg-manet-packetbb-sec-03.txt) a WG
document.

I would like to solicit comments on this document and making it a WG
document. Please respond to me and/or the MANET list.

Thanks.
Ian Chakeres

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 30 Mar 2010 14:51:23 +0200

I am also in favor of making packetBB-sec a WG document. We need such
security focused document in MANET at this stage, in my opinion, and it
seems to me packetBB-sec is the first logical step in this direction.
Emmanuel

2010/3/29 Yannick Lacharité <[email-masked]>