Subject: Re: [dtn-interest] Error in spec-10
From: Stephen Farrell <[email-masked]>
To: Jim Wyllie <[email-masked]>
Cc: [email-masked]
Date: Thu, 27 Sep 2007 16:57:02 +0100
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

I guess v6 is right? One to fix in auth-48.
Good catch,
S.

Jim Wyllie wrote:
> Hans Kruse and I noticed a typo in the current bundle spec when we were
> digging through version numbers.
> 
> Page 21:
> 
>    Version:   A 1-byte field indicating the version of the bundle
>       protocol that constructed this block.  The present document
>       describes version 0x05 of the bundle protocol.
> 
> Page 2:
> 
> This document describes version 6 of the Delay Tolerant Networking
>    (DTN) "bundle" protocol (BP).
> 
> Note the version number mismatch.

Date: Thu, 27 Sep 2007 11:16:23 -0400
From: Jim Wyllie <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Error in spec-10
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig391DB666D37E6A83EAD99051
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hans Kruse and I noticed a typo in the current bundle spec when we were
digging through version numbers.

Page 21:

   Version:   A 1-byte field indicating the version of the bundle
      protocol that constructed this block.  The present document
      describes version 0x05 of the bundle protocol.

Page 2:

This document describes version 6 of the Delay Tolerant Networking
   (DTN) "bundle" protocol (BP).

Note the version number mismatch.
--=20
Jim Wyllie
Master's Student
IRG Lab, Dept. of EE and CS
Ohio University

--------------enig391DB666D37E6A83EAD99051
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig391DB666D37E6A83EAD99051--

Date: Thu, 20 Sep 2007 17:03:51 +0100
To: Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Sender: [email-masked]

At Tuesday 18/09/2007 12:04 -0700, Kevin Fall wrote:
>please see attached.  The items with "**" in front of them may have  
>larger implications than those that don't.

Thanks. Some comments inline, unindented:

comments on draft-irtf-dtnrg-bundle-checksum-00.txt of Aug 2007

K. Fall, Sep 2007

Abstract
        remedies -> addresses
        heavy-weight (delete)

        "expense of divorcing security concerns from the few new ciphersuite
        definitions" seems a bit out of context... what does this
        really mean?  (in particular, what does "few" and "new" refer to)

        lengthily (delete)

Section 1:

        the statement:

          It is assumed that the "convergence layer adapters" that connect
          BAs to each other will detect and correct errors before presenting
          bundle data to the BAs themselves.

        is not quite correct.  While some people might hope that is true,
        and it indeed might often be true, a more accurate statement would
        say something like 'those applications requiring data integrity are
        responsible for implementing their own data checking functions'.

Stripping the end-to-end principle down to its bare minimum of application-level checking only works when the end applications are tightly coupled (or even coupled at all) - they detect an error, they can communicate and get a replacement packet sent. In DTN, this coupling and end-to-end direct application communication is broken by delay, disruption and distance. Getting a replacement for the errored-along-the-way bundle the receiving application has finally detected an error in may not be possible - or may take far too long and consume too much not-very-available network resource. This fact is independent of custody transfer, though use of custody transfer emphasises its importance. So, checking bundles for errors at individual hops, where closer coupling, and feedback between nodes terminating each hop, exists and resends are possible to compensate for errors, becomes much more important.

Also, nodes don't want to waste effort forwarding errored bundles onwards (vaguely analogous to IP over ATM EPD early packet discard, if anyone remembers that). You want to prevent errors as early as possible wherever possible, and do resends when you can. That isn't application-to-application in DTN scenarios.

        It might also be useful to refer to the effect of the security
        mecanisms at this point that accomplish the same.

The security mechanisms don't accomplish _quite_ the same - see discussion of keying in security considerations in the draft. 

Using null keys or private keys works slightly better at the lower convergence layer, where, if you're using a private key and the other host doesn't have it, you don't want to forward your traffic to that node anyway. At the higher bundle layer, with third-party custody and forwarding the choice of null keys or private keys boils down to a choice of some hop-by-hop reliability with the chance to detect errors and get a resend (null) or have some security with possible errors introduced once the bundle is finally forwarded to a node that has your key (private). With private keys, the third-party host cannot check that the encrypted content it is to relay has been received correctly. With null keys, the third-party host shouldn't get any encrypted traffic to relay. 

You need to be able to communicate reliably with third parties that don't share your security framework, so that they can do forwarding for you across gaps your nodes don't cover. Even null keying doesn't quite go far enough - you really need security inside a separate error check, so that the security can be optional and the error check mandatory, imo - and so that a node that doesn't have your private key can still be sure that the encrypted content it has temporary custody of is correctly received.

Interesting, btw, that Peter Lovell is now discussing the need for 'push' and 'pop' of security. Pushing an outer error-check around privately keyed content allows that content to be relayed error-free by a node that doesn't have the key.

        On what basis is it 'statistically likely' that transmission errors
        will go unnoticed or unchecked errors will be introduced within
        a BA's memory/storage/forwarding systems?  More specifically, for
        errors that could be addressed by checksums (mostly bit type errors),
        can you provide a modern reference to support this assertion?

It's a non-zero probability. We consider Stone's work as providing modern, well-done, and easy-to-grasp references.  Cosmic rays are unavoidable; their effects on RAM and the need for ECC RAM are well-known. See, for example, the 'Don't trust hardware' section of Stone's 2000 Sigcomm paper.

         The
        paragraphs that you have as examples are fine as to why this the
        bit errors -can- happen, any I would agree motivate the work, but
        they do not argue that these types of errors -are likely- to happen
        and be uncorrected.

        I like the writing of the paragraph ending section 1.

Section 2

        "pressed into use" -> "used"

        In 2.1 you argue the length bundle produced using SHA-256 for
        data integrity is not attractive, especially for small bundles.  
        If you could provide example(s) that would make this point clearer
        and you can use it compare against the proposed mechanism.

        The "bulk of code" argument I don't really find very compelling,
        given the forward progress of computer systems and the amount
        of code already required to do all of the other things.  If I were
        writing this document, I might mention this issue as a sort of
        aside, along the lines of "in some [e.g. embedded] systems, the
        implementation complexity of RSA can be significant.... blah blah"

My understanding is that most intended uses of DTN nodes are for embedded nodes -- that is, nodes not capable of running Windows.

Forward progress of *terrestrial* (high end, desktop) computer systems is one thing. Progress of rad-hard space systems is something else. Yes, Moore's law effects, exponential increases -- but, thanks to different exponential rates, I suspect the performance gap between the two is actually rising.

Section 3

        The phrase: "Since error-detection and rejection is a vital
        and absolutely essential component of reliable networking protocols"
        I don't necessarily agree with.  

The key word there is 'reliable'.

          This refers to what layer you
        implement this capability, and as mentioned above, the application
        is free to implement this and in general we advise folks to
        implement apps this way if they require it.

That's fine for a tightly-coupled app-to-app across a closed loop between apps - and the Internet falls into this closed loop; TCP uses a closed loop, etc. That advice doesn't work in DTN once disruption/delay open that loop and prevent easy resends - see above. The bundle layer still has access to hop-by-hop closed loops, so becomes the de facto 'highest layer' where end-to-end system efficiencies can be achieved by inspecting the bundle for errors at each hop.

        "labelled" I believe should be "labeled"

it's a common spelling outside the US.

        I'm not comfortable with the use of MUST where the accompanying
        compliance criteria involves the words "sufficiently dissimilar"
        and MUST NOT with "leads to their being construed as".  I believe
        this criteria is too subjective to be used with MUSTs.   Note that
        I do agree with your goal, however, to indicate that this
        mechanism is for integrity only.

        **It says "Since error-detection support is mandatory, this means
        that the minimal BSP elements that all Bundle Protocol implementations
        MUST support include: ...".  I don't believe this document introduced
        what would be mandatory or not, so I was suprised to find it
        listed here.  At one point we had agreed that "mandatoriness", in
        terms of significant capabilities, would be defined in separate
        RFCs.  Following along these lines, I believe this document
        should just define the various ways of doing things, and whether
        its mandatory or not should be deferred to a separate conversation.

        **Given the general approach here is to use existing forms of
        transformations with NULL keys, maybe it would be sensible to
        just establish an INSECURE bit that is orthogonal from the
        transofrmations, to indicate a NULL key.

        The comment that MD5 can be executed 2x faster than SHA1 should
        include a reference to the mentioned "benchmarking activities".
        It might also be worth mentioning that there is now a loss
        of faith in the efficacy of MD5 for security purposes, but that
        fact doesn't diminish its utility for this purpose.

        for the CRC32 variant, you say it MUST only be used on bundles
        with payload length < 64k.  Why this restriction? 

Risk of collisions. That should be 64kbits.

http://ieeexplore.ieee.org/xpls/abs_all.jsp?tp=&arnumber=1028931&isnumber=22107
32-bit cyclic redundancy codes for Internet applications
Koopman, P.
Dependable Systems and Networks, 2002. DSN 2002. Proceedings. International Conference on
Volume , Issue , 2002 Page(s): 459 - 468
Digital Object Identifier   10.1109/DSN.2002.1028931 

"Standardized 32-bit cyclic redundancy codes provide fewer bits of guaranteed error detection than they could, achieving a Hamming Distance (HD) of only 4 for maximum-length Ethernet messages, whereas HD=6 is possible. Although research has revealed improved codes, exploring the entire design space has previously been computationally intractable, even for special-purpose hardware. Moreover, no CRC polynomial has yet been found that satisfies an emerging need to attain both HD=6 for 12K bit messages and HD=4 for message lengths beyond 64 Kbits. "

The slightly weaker Ethernet CRC is recognised to have a threshold at 12Kbits. (Koopman happily references Stone.)

          If you
        use the "standard" polynomial for CRC32 you get any 1 or 2
        bit errors up to 4GB [Boudreau et al, 1994].

I presume you're referring to
P. E. Boudreau, W. C. Bergman and D. R. Irvin, Performance of a cyclic redundancy check and its interaction with a data scrambler, IBM Journal of Research and Development, vol 38 issue 6, Nov 1994, pp. 651-658.
http://domino.watson.ibm.com/tchjr/journalindex.nsf/4ac37cf0bdc4dd6a85256547004d47e1/fd7c0903aa2ec6c685256bfa0067fa97?OpenDocument
(has free copy)
http://portal.acm.org/citation.cfm?id=208121

A 2^32 = 4G*bit* transmission (ie 512KB) may well contain some burst errors longer than that.

        (Aside: the paper Ray, Koopman
                "Efficient High Hamming Distance CRCs for Embedded Networks"
                (DSN June 2006) may be of interest to you)

 http://www.ece.cmu.edu/~koopman/pubs/ray06_crcalgorithms.pdf 
That's a good introduction to CRCs for short messages and low-end performance.

        In 3.1 there is another discussion of what MUST be implemented.
        Please see earlier comment regardin MUSTs.
        Also, typo: "teh" -> "the"

        ** I see the use of some of the specified capabilities are
        tied together with custody transfer.  I'm not sure that
        is the best thing.  Rather it may make more sense to have
        the concept of "discard if errorful" a more general
        class of service or option to the sender, orthogonal from
        custody transfer, as I think you begin to describe on page 13.
        Why not take this approach in the current document? 

Custody transfer is imo important; sending on errored bundles that you already know are errored is rarely useful, while if you do do that, the scope of errors has to be bounded - only in payloads that can tolerate it, and not in header data (including mutable data, which requires per-hop checksum coverage). I think applications will want - no,  _expect_ - a reliable service from the bundle protocol.

          We don't
        need to re-issue the bundle protocol spec for it.  This might
        also mesh nicely with the earlier comment above regarding
        the 'insecure' flag.  This should be discussed I think.

Section 4

        The paragraph starting with "This design decision" and
        the following one, starting with "Ideally" needs to be
        in a separate 'rationale' document, if you care to write one.

I very much doubt we'll be writing that.

        **I specifically object to the phrase:
            It is well-understood that future revisions
            of the Bundle Protocol need to include appropriate checksums within
            the basic format of each block.

        for the reasons mentioned above. 

The need for reliability remains important. That should be stressed; the actual mechanism should probably not be prescribed. So: It is well-understood that future revisions of the Bundle Protocol need to provide mechanisms ensuring error detection and reliable delivery.

          I do not object to the portion
        that starts with "In order to limit overhead..."

        The paragraph starting with Using the same" needs to be
        in a separate 'rationale' document, if you care to write one.

Section 5

        Didn't you specify new codepoints for ciphersuites?

Section 6

        remove "limitations of", unless you are intending to
        specifically document them

>- K

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 

To: dtn interest <[email-masked]>
From: Kevin Fall <[email-masked]>
Date: Wed, 19 Sep 2007 14:30:11 -0700
Subject: [dtn-interest] IETF69 minutes
Sender: [email-masked]

--Apple-Mail-22--670669190
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Please find attached minutes from IETF69.  I will be uploading these  
to the official site soon, but if anybody has significant mods/ 
additions/comments this would be a good time to mention them...

- K
--Apple-Mail-22--670669190
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	x-unix-mode=0644;
	name=dtnrg-minutes-ietf69.txt
Content-Disposition: attachment;
	filename=dtnrg-minutes-ietf69.txt

DTNRG
Summary Minutes from IETF69

Intro & agenda; no changes
Document status:
	RFC 4838 issued
	BP spec done moving to IESG (real soon now)
	LTP in IRSG review
	Security docs:
		overview needs rev;
		bsp in work

	DTRNG has authored 50% of all IRTF I-Ds
	Encapsulation & prev hop drafts just refreshed
	TCP CL: Mike/Joerg posted supplemented earlier doc; should progress soonish editorial work to do
	Others:   sdnv doc - no objection to adopting that
	          key mgmt - in a mo
		  uni-CL - not ready ; update later
		  prophet - might need resubmission (not sure) - might be ready
		  multicast & re-tx docs -   others discussed today  cbhe - to be revived
	we need to organise a review of all these nearly done docs

News;  LTP/Saratoga to be presented at TSV area (see TSV area minutes for more)
Stephen Farrell - Key management draft already reported in Dublin
	km - sets out requirements; call for volunteers
	km - details

	related item: change to counter mode for crypto to ensure size(cleartext) == size(corresponding cyphertext)

Mike Demmer - DTN2 status; 2.4 release last week
Routing - DTLSR overiew, paper at SIGCOMM/NSDR;
prophet; flood router

Applications - send/rcv/ping; traceroute app; tunnel app (TCP/UDP over bundles);
dtnperf  Misc features - multi endpoint; dtnsim; neighbourhood discovery (bonjour in Apple)
Coming - security; swig for scripting (with Dirk); pub-sub API

Broken/not-done things: proactive fragmentation; flow control

Ref implementation
	Timeframe - 2.4 out; 2.4.1 patch soon; 2.5 in autumn incl. security

Wes Eddy - Checksum draft (on cisco site now, missed cutoff) [since posted to dtn-interest and as ID]
     Rationale for checksums
	Why not use BSP framework? (discussion)
	Long term proposal - add optional fields
	Q&A:   Why not use BSP security?
		You can. Use new ciphersuite/fixed-key/new-doc
		Application vs. BP-layer integrity provision
		Canonicalisation needed? Re-use mutable stuff where possible
		Mandatory/optional; integrity as part of security or not
		Do it as a ciphersuite? Agreed.

Tom Henderson - Describing ns-3 simulation (Univ. Wash. work/Boeing)
	Q&A:   Dirk - similar emulation extensions as for ns-2 planned?  Sort-of
	Kevin - persistent storage; link status robustness; high delay & directional antennas? could be done?
	A: Maybe in future, not yet.
	Mike D - DTN2 vs. ns-3 feature location? A: YMMV
	Stephen - release dates? real soon now; alpha by year-end-ish

Joerg Ott  Small simulation tool
	"ONE" for opportunistic networks
	Based on synthetic & trace-based mobility models
	Demo (incl viz) based on 100 nodes in Helsinki
	Used to evaluate different routing protocols to figure how motion affects them  Alpha version available

Lloyd Wood  - Saratoga changes
	Saratoga basics as in Dublin Planning to fly bundles/saratoga on UK DMC later this year
	Q&A:  Kevin - not sure who'll get 1st bundle in space (vs Colorado group)
	Kevin - interesting layering questions (answers would need thought)
	Kevin - beacons - would that be replaced by neighbour discovery?
	(next pres) not sure
	Kevin - pull (pub-sub etc) file ops might be useful outside this layer as well
	discussion about where bit-level reliablity is and if its fundamental

Jim Wylie - Neighbour/node discovery
	Problem statement (tends to be done in various ways at various layers) Generic/secure/EID-independent/re-usable/flexible/   scheme needed
	Proposal: like HELO from OSPF (CL independent?)
	
	Not a way to route packets; just one step in that process
	Terms: neighbour = same CL pitcher/catcher - both and you're a neighbour
	The proposal
	Q&A Stephen - what's a domain?
	A: a general system, e.g. "space"
	Kevin - what about other protocols, e.g. nhdp from manet? worth a look & saying how this differs
	Mike D - this replaces CL-specific discovery, but some CLs have/need that so why replace it?

Wrap  - Next meeting: probably Phili/IETF-71  Otherwise: maybe end-07/early-08  Upcoming publication venues/workshops (various)

--Apple-Mail-22--670669190--

Date: Wed, 19 Sep 2007 21:51:56 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: "Weiss, Howard" <[email-masked]>, Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Sender: [email-masked]

Wesley Eddy wrote:
> On Wed, Sep 19, 2007 at 04:57:18PM +0100, Stephen Farrell wrote:
>> Something just struck me. In your DMC slides I think you quote a
>> downlink of about 8Mbps. That's a lot less than 31% of 87Mbps so I
>> would have thought that if you can be runnning the hash calculation
>> in line with data transmission it might work. I'm probably missing
>> something though.
>>
> 
> Yes, UK-DMC has an 8 Mbps downlink.  Beijing-1 has a 40 Mbps downlink.
> In TSVAREA, at least, I also mentioned that in the pipeline is a 210
> Mbps downlink.  

Fair enough.

 > The exact numbers are unimportant though, as I hope we
> can agree that it would be silly to tailor the algorithms in the spec
> for one particular demo :).  

But a clear demonstration that sha-256 is too cpu intensive for a
real platform-of-interest would be useful still.

 > The point is that DTN nodes are expected to
> be light in resources and we should pick comparably light algorithms
> that accomplish what's needed without waste.

I think our disagreement is reflected in the above. My experience makes
me lean heavily towards specifying one ciphersuite for each purpose and
only going beyond that if I must. You seem to be much more open to
defining a bunch of different algorithms. Both positions have their
merits. (Oh, and I prefer mine:-)

S.

Date: Wed, 19 Sep 2007 21:50:28 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: "Weiss, Howard" <[email-masked]>, Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Sender: [email-masked]

Wesley Eddy wrote:
> That's not in scope for the current document IMO. The current BSP is
>> analagous to AH/ESP, we've yet to get to an IKE-equivalent, nor to
>> how to do routing - those would be separate documents for which there's
>> no need to wait. The current BSP is IMO nearly done. 
> 
> This is untrue.  The current BSP is *NOT* analogous to AH/ESP.  

We disagree.

 > The
> IPsec protocols either construct proper tunnels by encapsulation or
> operate end-to-end.  The BSP adds addresses (security-source and
> security-destination) in addition to the primary bundle block's
> addresses, without encapsulating.  This is quite different.

Different, but analagous.

S.

From: "Peter Lovell" <[email-masked]>
To: <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "Howard Weiss" <[email-masked]>, "Kevin Fall" <[email-masked]>, "DTN interest" <[email-masked]>
Subject: Re(2): [dtn-interest] comments on checksum draft
Date: Wed, 19 Sep 2007 15:06:19 -0400
Sender: [email-masked]

On Wed, Sep 19, 2007, Wesley Eddy <[email-masked]> wrote:

>On Wed, Sep 19, 2007 at 04:44:00PM +0100, Stephen Farrell wrote:
>> Wesley Eddy wrote:
>> >On Wed, Sep 19, 2007 at 03:19:26PM +0100, Stephen Farrell wrote:
>> >>Wes,
>> >>
>> >>>Absolutely ... that's one reason why I originally argued against putting
>> >>>these algorithms that are unsuitable for security into the BSP!  
>> >>IMO the process reason is the main point here - the current BSP stuff
>> >>is nearly done (not perfect, but nearly done) whereas we're just
>> >>starting out on the checksum thing. (Should be quicker though since
>> >>it inherits from the BSP.)
>> >
>> >
>> >Actually, I thought there were a few big questions remaining on the BSP
>> >itself.  The freshest one in my mind is how bundles are actually routed
>> >to the security-destination.  These questions were among the reasons I
>> >was hesitant to rely on the BSP for error-detection, not knowing in what
>> >ways it will have to change in order to be viable.
>> 
>> That's not in scope for the current document IMO. The current BSP is
>> analagous to AH/ESP, we've yet to get to an IKE-equivalent, nor to
>> how to do routing - those would be separate documents for which there's
>> no need to wait. The current BSP is IMO nearly done.
>> 
>
>
>This is untrue.  The current BSP is *NOT* analogous to AH/ESP.  The
>IPsec protocols either construct proper tunnels by encapsulation or
>operate end-to-end.  The BSP adds addresses (security-source and
>security-destination) in addition to the primary bundle block's
>addresses, without encapsulating.  This is quite different.

Chatting just now with Howie about this, I realize that the push/pop
scheme for security-destination would also eliminate another nasty problem.

The recent discussion-draft included a section pointing out an issue
with "overlapping security zones" and the kind of trouble that results.
The push/pop scheme makes that impossible.

That's not for this cycle though. But let's take it up in a few weeks.

Regards.....Peter

Date: Wed, 19 Sep 2007 12:51:30 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: "Weiss, Howard" <[email-masked]>, Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Sender: [email-masked]

This is the absolute last that I will post on MD5.  In security circles,
the FUD has been dispelled long ago, let's look at their documents to
do the same here.

A quote from RFC 4270 which describes the impact of attacks on hashes
to the protocols that use them:

   Of the above methods, only the first two are affected by collision
   attacks, and even then, only in limited circumstances.

Use for integrity protection is specifcally named as unaffected as
described in this RFC (described as: "Integrity protection.  It is
common to compare a hash value that is received out-of-band for a file
with the hash value of the file after it is received over an unsecured
protocol such as FTP.", which is how we've used it); the two affected
uses that it's refering to involve digital signatures.

It is a mis-representation to claim that MD5 is unsuitable for use in
other protocols, even security protocols.  From RFC 4894:

   As described in earlier sections, IKE and IPsec themselves are not
   susceptible to any known collision-reduction attacks on hash
   functions.  Thus, implementors do not need to make changes such as
   prohibiting the use of MD5 or SHA-1.  The mandatory and suggested
   algorithms for IKEv2 and IPsec are given in [IKEv2Algs] and
   [IPsecAlgs].

   Note that some IKE and IPsec users will misunderstand the relevance
   of the known attacks and want to use "stronger" hash functions.
   Thus, implementors should strongly consider adding support for
   alternatives,

Let's ponder this ...

Date: Wed, 19 Sep 2007 12:27:34 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: "Weiss, Howard" <[email-masked]>, Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Sep 19, 2007 at 04:57:18PM +0100, Stephen Farrell wrote:
> 
> Something just struck me. In your DMC slides I think you quote a
> downlink of about 8Mbps. That's a lot less than 31% of 87Mbps so I
> would have thought that if you can be runnning the hash calculation
> in line with data transmission it might work. I'm probably missing
> something though.
> 

Yes, UK-DMC has an 8 Mbps downlink.  Beijing-1 has a 40 Mbps downlink.
In TSVAREA, at least, I also mentioned that in the pipeline is a 210
Mbps downlink.  The exact numbers are unimportant though, as I hope we
can agree that it would be silly to tailor the algorithms in the spec
for one particular demo :).  The point is that DTN nodes are expected to
be light in resources and we should pick comparably light algorithms
that accomplish what's needed without waste.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Wed, 19 Sep 2007 12:21:18 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: "Weiss, Howard" <[email-masked]>, Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Sep 19, 2007 at 04:44:00PM +0100, Stephen Farrell wrote:
> Wesley Eddy wrote:
> >On Wed, Sep 19, 2007 at 03:19:26PM +0100, Stephen Farrell wrote:
> >>Wes,
> >>
> >>>Absolutely ... that's one reason why I originally argued against putting
> >>>these algorithms that are unsuitable for security into the BSP!  
> >>IMO the process reason is the main point here - the current BSP stuff
> >>is nearly done (not perfect, but nearly done) whereas we're just
> >>starting out on the checksum thing. (Should be quicker though since
> >>it inherits from the BSP.)
> >
> >
> >Actually, I thought there were a few big questions remaining on the BSP
> >itself.  The freshest one in my mind is how bundles are actually routed
> >to the security-destination.  These questions were among the reasons I
> >was hesitant to rely on the BSP for error-detection, not knowing in what
> >ways it will have to change in order to be viable.
> 
> That's not in scope for the current document IMO. The current BSP is
> analagous to AH/ESP, we've yet to get to an IKE-equivalent, nor to
> how to do routing - those would be separate documents for which there's
> no need to wait. The current BSP is IMO nearly done.
> 

This is untrue.  The current BSP is *NOT* analogous to AH/ESP.  The
IPsec protocols either construct proper tunnels by encapsulation or
operate end-to-end.  The BSP adds addresses (security-source and
security-destination) in addition to the primary bundle block's
addresses, without encapsulating.  This is quite different.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] comments on checksum draft
Date: Wed, 19 Sep 2007 12:05:45 -0400
From: "Weiss, Howard" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, <[email-masked]>
Cc: "Kevin Fall" <[email-masked]>, "DTN interest" <[email-masked]>
Sender: [email-masked]

One more thing to remember about performance numbers - as we all know a
lot depends on who implemented the algorithm and how.  Just because the
benchmarks at cryptopp.com show such bad numbers for MD5 vs. SHA-x, that
may simply be a reflection on not only the complexity of the algorithm
but also the expertise of the programmer.  I still remember the IETF
debate over authentication before encryption or vice-versa.  The
strongest arguments to encrypt a packet first and then MAC it was
because of the much lower CPU overhead involved in checking a MAC vs.
decrypting the packet only to find it was forged or modified.  This was
because (at the time) DES was such a CPU hog.  But processor speeds
increased and expertise in coding DES more efficiently made this a
non-issue.  

Again, we're not gonna go back to Win95 simply because it ran more
efficiently (when it ran....).

Howie

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2007 11:44 AM
> To: [email-masked]
> Cc: Weiss, Howard; Kevin Fall; DTN interest
> Subject: Re: [dtn-interest] comments on checksum draft
> 
> 
> 
> Wesley Eddy wrote:
> > On Wed, Sep 19, 2007 at 03:19:26PM +0100, Stephen Farrell wrote:
> >> Wes,
> >>
> >>> Absolutely ... that's one reason why I originally argued against
> putting
> >>> these algorithms that are unsuitable for security into the BSP!
> >> IMO the process reason is the main point here - the current BSP
> stuff
> >> is nearly done (not perfect, but nearly done) whereas we're just
> >> starting out on the checksum thing. (Should be quicker though since
> >> it inherits from the BSP.)
> >
> >
> > Actually, I thought there were a few big questions remaining on the
> BSP
> > itself.  The freshest one in my mind is how bundles are actually
> routed
> > to the security-destination.  These questions were among the reasons
> I
> > was hesitant to rely on the BSP for error-detection, not knowing in
> what
> > ways it will have to change in order to be viable.
> 
> That's not in scope for the current document IMO. The current BSP is
> analagous to AH/ESP, we've yet to get to an IKE-equivalent, nor to
> how to do routing - those would be separate documents for which
there's
> no need to wait. The current BSP is IMO nearly done.
> 
> >>> I also
> >>> find it VERY STRANGE that we keep having this conversation about
> MD5 and
> >>> nobody voices the same problem with CRC-32 :).
> >> I've tried to explain this before and obviously failed.
> >> Here's another attempt:
> >>
> >>    MD5 made security claims, but has now been broken.
> >>    CRC-32 makes no security claims, so is as good as it ever was.
> >>    => Deprecate MD5, but its as ok as it ever was to use CRC-32.
> >
> >
> > 1321 _conjectured_ about security properties, it made no claims, so
> even
> > this is a false premise.  Rivest was clear about this distinction in
> > 1321.
> 
> MD5 effectively aimed for 2^64 collision resistance and has now been
> shown to be about 2^40. I don't see any point in quibbling about
> that here. MD5 is broken as far as we're concerned. (If you want to
> dispute that, I guess CFRG will/won't welcome you with open arms:-)
> 
>  > In a previous thread, I thought we converged on this not being
> > a technical point, anyways.
> 
> Nonetheless it is significant. The algorithm is no longer fit
> for purpose and is being retired everywhere.
> 
> >> Having said that I'd love to see concrete evidence as to why
SHA-256
> >> isn't acceptable on some hardware that people actually want to use.
> >> (Maybe your SSDR? Are the numbers in one of the papers?)
> >>
> >> I don't disbelieve you but would like to see numbers since I do
> think
> >> its at least possible that even quite challenged nodes can do best
> >> curent practice hashing (SHA-256). I wouldn't be surprised if in
> >> some cases the CPU was just spinning for periods when I/O is
> >> happening, sufficient to allow the hashing to be done. If things
> >> turned out that way, then I'd argue to only define a SHA-256 based
> >> checksum ciphersuite and nothing else.
> >
> > RFC 1810 has numbers on MD5, showing that it was difficult
> (impossible?)
> > to reach 100 Mbps on high-end machines of the time.  Though these
> machines
> > are dated for sure, some devices used in DTNs (proposed for use in
> > DTNs?) are of similar resources to the machines in RFC 1810.  For
> > instance a 200 Mhz PPC on a satellite is not too far away from the
> 190
> > Mhz Alpha that did MD5 at 87 Mbps in RFC 1810.  Based on Wei Dai's
> > benchmarks of code that is usually quite optimized
> > (http://www.cryptopp.com/benchmarks.html), SHA-1 only gets 60% of
the
> > throughput as MD5, and SHA-256 is even worse at 31% of MD5's
> throughput.
> >
> > Also note that some DTNs have concerns of power-usage and
> > heat-dissipation in addition to concerns with latency and throughput
> of
> > hash functions.  Each instruction costs multiple resources.
> 
> I agree with all that. However, I'd still love to see numbers for
> sha-256 on e.g. your SSDR or some bit of kit someone actually wants
> to use and an explanation for why its too slow.
> 
> If we're going to include any "weak" checksum then I think there is
> an onus on us to explicitly justify its presence by showing that
> the BCP case (sha-256) won't work, that the "weak" checksum will
> work and that there're no ancilliary bad things that happen due
> to its being defined.
> 
> If its not possible to get those numbers, then I guess we'll have to
> figure out what to do without them, but if what you're saying is
> right, then it'd be pretty convincing evidence. (Worth including
> in/referencing from the I-D maybe.)
> 
> I'm also generally not a fan of having loads of ciphersuites
> since it hurts interop, sometimes quite badly. Ideally we'd
> define only one (good one) for each purpose and stick with that
> until there's a good reason to need more.
> 
> S.

Date: Wed, 19 Sep 2007 16:58:18 +0100
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: [email-masked], Howard Weiss <[email-masked]>, Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Sender: [email-masked]

Peter Lovell wrote:
> Of course, some might argue that this isn't BSP's concern, and that we
> should leave routing decisions to the routing code. While I have
> sympathy for that notion, if BSP has created the route dependency then
> we have some responsibility to help with the solution. 

Figuring out possible routing answers is fine. I don't think we
should put those in the BSP spec. Maybe in the security overview?

S.

Date: Wed, 19 Sep 2007 16:57:18 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: "Weiss, Howard" <[email-masked]>, Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Sender: [email-masked]

Wesley Eddy wrote:

> RFC 1810 has numbers on MD5, showing that it was difficult (impossible?)
> to reach 100 Mbps on high-end machines of the time.  Though these machines
> are dated for sure, some devices used in DTNs (proposed for use in
> DTNs?) are of similar resources to the machines in RFC 1810.  For
> instance a 200 Mhz PPC on a satellite is not too far away from the 190
> Mhz Alpha that did MD5 at 87 Mbps in RFC 1810.  Based on Wei Dai's
> benchmarks of code that is usually quite optimized
> (http://www.cryptopp.com/benchmarks.html), SHA-1 only gets 60% of the
> throughput as MD5, and SHA-256 is even worse at 31% of MD5's throughput.

Something just struck me. In your DMC slides I think you quote a
downlink of about 8Mbps. That's a lot less than 31% of 87Mbps so I
would have thought that if you can be runnning the hash calculation
in line with data transmission it might work. I'm probably missing
something though.

S.

From: "Peter Lovell" <[email-masked]>
To: <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "Howard Weiss" <[email-masked]>, "Kevin Fall" <[email-masked]>, "DTN interest" <[email-masked]>
Subject: Re(2): [dtn-interest] comments on checksum draft
Date: Wed, 19 Sep 2007 11:52:05 -0400
Sender: [email-masked]

On Wed, Sep 19, 2007, Wesley Eddy <[email-masked]> wrote:

>Actually, I thought there were a few big questions remaining on the BSP
>itself.  The freshest one in my mind is how bundles are actually routed
>to the security-destination.  These questions were among the reasons I
>was hesitant to rely on the BSP for error-detection, not knowing in what
>ways it will have to change in order to be viable.

Hi Wes,

the routing question is indeed high on my list but I decided not to
address it in this update cycle for the spec.

The best solution I've heard so far is the one you made - to push the
security-destination as the intermediate bundle destination. The BSP
code there then pops the address and restores the original bundle-
destination value.

I'm thinking through various scenarios to try to see if we break
anything and, if so, how badly.

Of course, some might argue that this isn't BSP's concern, and that we
should leave routing decisions to the routing code. While I have
sympathy for that notion, if BSP has created the route dependency then
we have some responsibility to help with the solution. 

Cheers.....Peter

Date: Wed, 19 Sep 2007 16:44:00 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: "Weiss, Howard" <[email-masked]>, Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Sender: [email-masked]

Wesley Eddy wrote:
> On Wed, Sep 19, 2007 at 03:19:26PM +0100, Stephen Farrell wrote:
>> Wes,
>>
>>> Absolutely ... that's one reason why I originally argued against putting
>>> these algorithms that are unsuitable for security into the BSP!  
>> IMO the process reason is the main point here - the current BSP stuff
>> is nearly done (not perfect, but nearly done) whereas we're just
>> starting out on the checksum thing. (Should be quicker though since
>> it inherits from the BSP.)
> 
> 
> Actually, I thought there were a few big questions remaining on the BSP
> itself.  The freshest one in my mind is how bundles are actually routed
> to the security-destination.  These questions were among the reasons I
> was hesitant to rely on the BSP for error-detection, not knowing in what
> ways it will have to change in order to be viable.

That's not in scope for the current document IMO. The current BSP is
analagous to AH/ESP, we've yet to get to an IKE-equivalent, nor to
how to do routing - those would be separate documents for which there's
no need to wait. The current BSP is IMO nearly done.

>>> I also
>>> find it VERY STRANGE that we keep having this conversation about MD5 and
>>> nobody voices the same problem with CRC-32 :).
>> I've tried to explain this before and obviously failed.
>> Here's another attempt:
>>
>>    MD5 made security claims, but has now been broken.
>>    CRC-32 makes no security claims, so is as good as it ever was.
>>    => Deprecate MD5, but its as ok as it ever was to use CRC-32.
> 
> 
> 1321 _conjectured_ about security properties, it made no claims, so even
> this is a false premise.  Rivest was clear about this distinction in
> 1321.  

MD5 effectively aimed for 2^64 collision resistance and has now been
shown to be about 2^40. I don't see any point in quibbling about
that here. MD5 is broken as far as we're concerned. (If you want to
dispute that, I guess CFRG will/won't welcome you with open arms:-)

 > In a previous thread, I thought we converged on this not being
> a technical point, anyways.

Nonetheless it is significant. The algorithm is no longer fit
for purpose and is being retired everywhere.

>> Having said that I'd love to see concrete evidence as to why SHA-256
>> isn't acceptable on some hardware that people actually want to use.
>> (Maybe your SSDR? Are the numbers in one of the papers?)
>>
>> I don't disbelieve you but would like to see numbers since I do think
>> its at least possible that even quite challenged nodes can do best
>> curent practice hashing (SHA-256). I wouldn't be surprised if in
>> some cases the CPU was just spinning for periods when I/O is
>> happening, sufficient to allow the hashing to be done. If things
>> turned out that way, then I'd argue to only define a SHA-256 based
>> checksum ciphersuite and nothing else.
> 
> RFC 1810 has numbers on MD5, showing that it was difficult (impossible?)
> to reach 100 Mbps on high-end machines of the time.  Though these machines
> are dated for sure, some devices used in DTNs (proposed for use in
> DTNs?) are of similar resources to the machines in RFC 1810.  For
> instance a 200 Mhz PPC on a satellite is not too far away from the 190
> Mhz Alpha that did MD5 at 87 Mbps in RFC 1810.  Based on Wei Dai's
> benchmarks of code that is usually quite optimized
> (http://www.cryptopp.com/benchmarks.html), SHA-1 only gets 60% of the
> throughput as MD5, and SHA-256 is even worse at 31% of MD5's throughput.
> 
> Also note that some DTNs have concerns of power-usage and
> heat-dissipation in addition to concerns with latency and throughput of
> hash functions.  Each instruction costs multiple resources.

I agree with all that. However, I'd still love to see numbers for
sha-256 on e.g. your SSDR or some bit of kit someone actually wants
to use and an explanation for why its too slow.

If we're going to include any "weak" checksum then I think there is
an onus on us to explicitly justify its presence by showing that
the BCP case (sha-256) won't work, that the "weak" checksum will
work and that there're no ancilliary bad things that happen due
to its being defined.

If its not possible to get those numbers, then I guess we'll have to
figure out what to do without them, but if what you're saying is
right, then it'd be pretty convincing evidence. (Worth including
in/referencing from the I-D maybe.)

I'm also generally not a fan of having loads of ciphersuites
since it hurts interop, sometimes quite badly. Ideally we'd
define only one (good one) for each purpose and stick with that
until there's a good reason to need more.

S.

Date: Wed, 19 Sep 2007 11:06:10 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: "Weiss, Howard" <[email-masked]>, Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Sep 19, 2007 at 03:19:26PM +0100, Stephen Farrell wrote:
> 
> Wes,
> 
> >Absolutely ... that's one reason why I originally argued against putting
> >these algorithms that are unsuitable for security into the BSP!  
> 
> IMO the process reason is the main point here - the current BSP stuff
> is nearly done (not perfect, but nearly done) whereas we're just
> starting out on the checksum thing. (Should be quicker though since
> it inherits from the BSP.)

Actually, I thought there were a few big questions remaining on the BSP
itself.  The freshest one in my mind is how bundles are actually routed
to the security-destination.  These questions were among the reasons I
was hesitant to rely on the BSP for error-detection, not knowing in what
ways it will have to change in order to be viable.

> > I also
> >find it VERY STRANGE that we keep having this conversation about MD5 and
> >nobody voices the same problem with CRC-32 :).
> 
> I've tried to explain this before and obviously failed.
> Here's another attempt:
> 
>    MD5 made security claims, but has now been broken.
>    CRC-32 makes no security claims, so is as good as it ever was.
>    => Deprecate MD5, but its as ok as it ever was to use CRC-32.

1321 _conjectured_ about security properties, it made no claims, so even
this is a false premise.  Rivest was clear about this distinction in
1321.  In a previous thread, I thought we converged on this not being
a technical point, anyways.

> Having said that I'd love to see concrete evidence as to why SHA-256
> isn't acceptable on some hardware that people actually want to use.
> (Maybe your SSDR? Are the numbers in one of the papers?)
>
> I don't disbelieve you but would like to see numbers since I do think
> its at least possible that even quite challenged nodes can do best
> curent practice hashing (SHA-256). I wouldn't be surprised if in
> some cases the CPU was just spinning for periods when I/O is
> happening, sufficient to allow the hashing to be done. If things
> turned out that way, then I'd argue to only define a SHA-256 based
> checksum ciphersuite and nothing else.

RFC 1810 has numbers on MD5, showing that it was difficult (impossible?)
to reach 100 Mbps on high-end machines of the time.  Though these machines
are dated for sure, some devices used in DTNs (proposed for use in
DTNs?) are of similar resources to the machines in RFC 1810.  For
instance a 200 Mhz PPC on a satellite is not too far away from the 190
Mhz Alpha that did MD5 at 87 Mbps in RFC 1810.  Based on Wei Dai's
benchmarks of code that is usually quite optimized
(http://www.cryptopp.com/benchmarks.html), SHA-1 only gets 60% of the
throughput as MD5, and SHA-256 is even worse at 31% of MD5's throughput.

Also note that some DTNs have concerns of power-usage and
heat-dissipation in addition to concerns with latency and throughput of
hash functions.  Each instruction costs multiple resources.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Wed, 19 Sep 2007 15:19:26 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: "Weiss, Howard" <[email-masked]>, Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Sender: [email-masked]

Wes,

> Absolutely ... that's one reason why I originally argued against putting
> these algorithms that are unsuitable for security into the BSP!  

IMO the process reason is the main point here - the current BSP stuff
is nearly done (not perfect, but nearly done) whereas we're just
starting out on the checksum thing. (Should be quicker though since
it inherits from the BSP.)

 > I also
> find it VERY STRANGE that we keep having this conversation about MD5 and
> nobody voices the same problem with CRC-32 :).

I've tried to explain this before and obviously failed.
Here's another attempt:

    MD5 made security claims, but has now been broken.
    CRC-32 makes no security claims, so is as good as it ever was.
    => Deprecate MD5, but its as ok as it ever was to use CRC-32.

Having said that I'd love to see concrete evidence as to why SHA-256
isn't acceptable on some hardware that people actually want to use.
(Maybe your SSDR? Are the numbers in one of the papers?)

I don't disbelieve you but would like to see numbers since I do think
its at least possible that even quite challenged nodes can do best
curent practice hashing (SHA-256). I wouldn't be surprised if in
some cases the CPU was just spinning for periods when I/O is
happening, sufficient to allow the hashing to be done. If things
turned out that way, then I'd argue to only define a SHA-256 based
checksum ciphersuite and nothing else.

S.

Date: Wed, 19 Sep 2007 09:48:32 -0400
From: Wesley Eddy <[email-masked]>
To: "Weiss, Howard" <[email-masked]>
Cc: Stephen Farrell <[email-masked]>, Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Sep 19, 2007 at 08:39:32AM -0400, Weiss, Howard wrote:
> I agree with Stephen - an "insecure bit" is just bad practice.  If this
> is desireable, specify a new cipher suite.

Ok, so it sounds like we did the right thing in the draft and can leave
that part alone.

> As for the MD5 vs. SHA-1 issue.  Yes, MD5 does run faster but so what?
> Windows 98 ran on Pentium 1 processors with 128M RAM.  You couldn't even
> boot VISTA on that hardware (lets not get into Windoze vs. Unix vs.
> Linux debates).

In the DTN world it is very reasonable to assume that the platforms will
be challenged and stay challenged rather than matching PCs in terms of
computational resources, as we scale down to smaller and smaller nodes
that use less-and-less power with more-and-more expected of them.

> If MD5 is flawed (and there is a sizable part of the
> community who believe it is) then we should simply abandon it.  Likewise
> SHA-1, while still ok for the most part, is also headed for extinction
> (the US govt is mandating a move to SHA-256 by 2010 - yeah they are also
> mandating IPv6....).  But nevertheless, we should not be promulgating
> flawed algorithms that may be utilized for many years in the future if
> we know (or suspect) them today.

Absolutely ... that's one reason why I originally argued against putting
these algorithms that are unsuitable for security into the BSP!  I also
find it VERY STRANGE that we keep having this conversation about MD5 and
nobody voices the same problem with CRC-32 :).

In the draft, we discussed the issue of using these algorithms within a
framework intended for security services and put "INSECURE" into the
ciphersuite mnemonics to be sure that people understood we were making
no security claims.  What did you think of that when you read it?

> One other comment on the use of "shortcuts" in code other than crypto.
> >From a overall system security perspective, taking "shortcuts" is the
> road to cyber disaster.  I can't tell you how many times I've seen code
> that saves a couple of bytes here and there or saves a few CPU cycles
> and is then exploitable because the major thrust of the shortcut was to
> save some resources without proper thought being given to any other side
> affects. This is one of the reasons why there are so many requirements
> layed down for good crypto code (and why for so long the govt was loathe
> to certify software crypto implementations).

Absolutely ... and I think this much was clear in the draft; we're not
talking about a shoddy imlementation, but rather a non-existent one.
E.g. using CRC-32 rather than RSA signatures, there's an order of
magnitude difference in code size and computation, but both are just as
good for detecting flipped bits.  This is especially good for
intermediate nodes to process, because checksum validation is much less
of a DoS than signature validation.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] comments on checksum draft
Date: Wed, 19 Sep 2007 08:39:32 -0400
From: "Weiss, Howard" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, <[email-masked]>
Cc: "Kevin Fall" <[email-masked]>, "DTN interest" <[email-masked]>
Sender: [email-masked]

I agree with Stephen - an "insecure bit" is just bad practice.  If this
is desireable, specify a new cipher suite.

As for the MD5 vs. SHA-1 issue.  Yes, MD5 does run faster but so what?
Windows 98 ran on Pentium 1 processors with 128M RAM.  You couldn't even
boot VISTA on that hardware (lets not get into Windoze vs. Unix vs.
Linux debates).  If MD5 is flawed (and there is a sizable part of the
community who believe it is) then we should simply abandon it.  Likewise
SHA-1, while still ok for the most part, is also headed for extinction
(the US govt is mandating a move to SHA-256 by 2010 - yeah they are also
mandating IPv6....).  But nevertheless, we should not be promulgating
flawed algorithms that may be utilized for many years in the future if
we know (or suspect) them today.

One other comment on the use of "shortcuts" in code other than crypto.
>From a overall system security perspective, taking "shortcuts" is the
road to cyber disaster.  I can't tell you how many times I've seen code
that saves a couple of bytes here and there or saves a few CPU cycles
and is then exploitable because the major thrust of the shortcut was to
save some resources without proper thought being given to any other side
affects. This is one of the reasons why there are so many requirements
layed down for good crypto code (and why for so long the govt was loathe
to certify software crypto implementations).

Howie

> -----Original Message-----
> From: [email-masked] [mailto:dtn-interest-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Tuesday, September 18, 2007 5:32 PM
> To: [email-masked]
> Cc: Kevin Fall; DTN interest
> Subject: Re: [dtn-interest] comments on checksum draft
> 
> 
> 
> Wesley Eddy wrote:
> 
> >> 	**Given the general approach here is to use existing forms of
> >> 	transformations with NULL keys, maybe it would be sensible to
> >> 	just establish an INSECURE bit that is orthogonal from the
> >> 	transofrmations, to indicate a NULL key.
> >
> >
> > Seems logical.
> 
> I'd prefer we didn't do that - it impinges on proper key mgmt and
> will raise red flags at review time. Just defining the ciphersuite
> is the better way IMO (ciphersuites being our additional degree
> of freedom) and is what we did with LTP. (And taking one April 1
> RFC seriously should be enough for any RG:-)
> 
> >> 	It might also be worth mentioning that there is now a loss
> >> 	of faith in the efficacy of MD5 for security purposes, but that
> >> 	fact doesn't diminish its utility for this purpose.
> >
> >
> > Ok, and the difference between MD5 and HMAC-MD5 is relevant here as
> well.
> 
> Actually, I'd delete MD5 entirely unless there's a specific reason to
> retain it. (HMAC-MD5 with a fixed key is ok though.) There are
> people out there who still think md5 is secure (we even met one last
> week who didn't like it 'cause he'd never heard of it:-) so we can't
> assume everyone's up to speed on hash function developments from the
> last couple of years.
> 
> S.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Tue, 18 Sep 2007 22:32:25 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Sender: [email-masked]

Wesley Eddy wrote:

>> 	**Given the general approach here is to use existing forms of
>> 	transformations with NULL keys, maybe it would be sensible to
>> 	just establish an INSECURE bit that is orthogonal from the
>> 	transofrmations, to indicate a NULL key.
> 
> 
> Seems logical.

I'd prefer we didn't do that - it impinges on proper key mgmt and
will raise red flags at review time. Just defining the ciphersuite
is the better way IMO (ciphersuites being our additional degree
of freedom) and is what we did with LTP. (And taking one April 1
RFC seriously should be enough for any RG:-)

>> 	It might also be worth mentioning that there is now a loss
>> 	of faith in the efficacy of MD5 for security purposes, but that
>> 	fact doesn't diminish its utility for this purpose.
> 
> 
> Ok, and the difference between MD5 and HMAC-MD5 is relevant here as well.

Actually, I'd delete MD5 entirely unless there's a specific reason to
retain it. (HMAC-MD5 with a fixed key is ok though.) There are
people out there who still think md5 is secure (we even met one last
week who didn't like it 'cause he'd never heard of it:-) so we can't
assume everyone's up to speed on hash function developments from the
last couple of years.

S.

Date: Tue, 18 Sep 2007 22:23:14 +0100
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
CC: Peter Lovell <[email-masked]>, dtn interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Sender: [email-masked]

In any case, since there's no plan that the checksum document
obsoletes the BP spec (unless we want that) it doesn't much
matter what draft-irtf-dtnrg-bundle-checksum says about the BP spec.
(In terms of changes; additions are fine.)

But, I think its not appropriate to do that since its opaque for
developers, so if someone wants checksums to be mandatory then we'd
need to rewrite the bundle spec that way. I doubt we want that
now so would expect that that text will be expunged in a future
version of the checksum draft.

S.

Kevin Fall wrote:
> I believe what we had settled on was the idea that you can have a 
> document that specifies something that is or is not required (by some 
> other doc), but that if it is used, there can be MUSTs.  That may sound 
> confusing, but what I mean is that you can define something like bundle 
> security such that if security is used then the MUSTs have to be 
> implemented.
> 
> The checksum document as written requires -all- bundle implementations 
> to include the proposed functionality.  I wanted to red-flag that item, 
> because  in some (most?) of the scenarios to date, this functionality 
> was not required or deemed necessary.  If we collectively really believe 
> this to be critical at this point then we can impose the requirement 
> that all implementations do it, but at some level I would prefer to just 
> describe the capability in detail, and leave it to another document to 
> define which RFCs are to be implemented in order to achieve what 
> results.  Even this way we could issue an RFC that says 'the bundle 
> protocol now means RFCxxx and RFCyyy to be compliant'  (whatever it 
> means to be compliant to an experimental protocol is arguable, but 
> nevertheless).  This mimics the way the host requirements RFC worked, or 
> what at least was the occasional list of 'standard' rfcs.
> 
> - K
> 
> On Sep 18, 2007, at 12:30 PM@Sep 18, 2007, Peter Lovell wrote:
> 
>> Hi Kevin,
>>
>> On Tue, Sep 18, 2007, Kevin Fall <[email-masked]> wrote:
>>
>>> please see attached.  The items with "**" in front of them may have
>>> larger implications than those that don't.
>>>
>>> - K
>>
>> and one of the ** sections is ...
>>
>>  **It says "Since error-detection support is mandatory, this means
>>     that the minimal BSP elements that all Bundle Protocol 
>> implementations
>>     MUST support include: ...".  I don't believe this document introduced
>>     what would be mandatory or not, so I was suprised to find it
>>     listed here.  At one point we had agreed that "mandatoriness", in
>>     terms of significant capabilities, would be defined in separate
>>     RFCs.
>>
>>
>> At the moment, the Bundle Security Protocol spec does have some
>> statements on mandatoriness, specifically that three particular
>> ciphersuites MUST be implemented (if you implement BSP at all, that is).
>>
>> In light of your comment, is that a correct thing to say in the BSP
>> spec? I don't have a specific issue either way - it's just that I don't
>> want to keep it in the spec if it had been decided that we shouldn't.
>>
>> Thanks.....Peter
>>
>>
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Tue, 18 Sep 2007 16:57:09 -0400
From: Wesley Eddy <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: DTN interest <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Reply-To: [email-masked]
Sender: [email-masked]

On Tue, Sep 18, 2007 at 12:04:43PM -0700, Kevin Fall wrote:
> please see attached.  The items with "**" in front of them may have  
> larger implications than those that don't.

Thanks; here is some discussion of the parts that aren't just editorial:

> Section 1:
> 
> 	the statement:
> 
> 	  It is assumed that the "convergence layer adapters" that connect
> 	  BAs to each other will detect and correct errors before presenting
> 	  bundle data to the BAs themselves.
> 
> 	is not quite correct.  While some people might hope that is true,
> 	and it indeed might often be true, a more accurate statement would
> 	say something like 'those applications requiring data integrity are
> 	responsible for implementing their own data checking functions'.

Is there a reference we can use for that?  Maybe part of 4838?  I looked
in 4838, but didn't find a clear statement saying that this was either a
DTN application's job or the bundle protocol's job.  As an
application-writer, I'd be prone to assuming the protocol handled it for
me since 4838 talks so much about being able to provide reliability when
requested.

> 	On what basis is it 'statistically likely' that transmission errors
> 	will go unnoticed or unchecked errors will be introduced within
> 	a BA's memory/storage/forwarding systems?  More specifically, for
> 	errors that could be addressed by checksums (mostly bit type errors),
> 	can you provide a modern reference to support this assertion?  The
> 	paragraphs that you have as examples are fine as to why this the
> 	bit errors -can- happen, any I would agree motivate the work, but
> 	they do not argue that these types of errors -are likely- to happen
> 	and be uncorrected.

I think we could take those 2 words out without any loss if there is
doubt about them. 

> 	I like the writing of the paragraph ending section 1.

The 2119 language? :)

> 	In 2.1 you argue the length bundle produced using SHA-256 for
> 	data integrity is not attractive, especially for small bundles.  
> 	If you could provide example(s) that would make this point clearer
> 	and you can use it compare against the proposed mechanism.

We could do this.

> 	The "bulk of code" argument I don't really find very compelling,
> 	given the forward progress of computer systems and the amount
> 	of code already required to do all of the other things.  If I were
> 	writing this document, I might mention this issue as a sort of
> 	aside, along the lines of "in some [e.g. embedded] systems, the
> 	implementation complexity of RSA can be significant.... blah blah"

I could provide lines of code counts from the UK-DMC code if it would
be illustrative.  It turns out that "all of the other things" can be
done incredibly simply by taking shortcuts or making assumptions in some
deployment cases, whereas if you have to do crypto, you have to do it
for real with no shortcuts.

> 	The phrase: "Since error-detection and rejection is a vital
> 	and absolutely essential component of reliable networking protocols"
> 	I don't necessarily agree with.  This refers to what layer you
> 	implement this capability, and as mentioned above, the application
> 	is free to implement this and in general we advise folks to
> 	implement apps this way if they require it.

I'm fine if that's what we want to decide, but I wish this point was
clear in the architecture document or the bundle protocol spec.  It
won't be pleasant if users have to discover through their own trials
and tribulations that they have some additional responsibilities that
they were assumed to be aware of.

> 	I'm not comfortable with the use of MUST where the accompanying
> 	compliance criteria involves the words "sufficiently dissimilar"
> 	and MUST NOT with "leads to their being construed as".  I believe
> 	this criteria is too subjective to be used with MUSTs.   Note that
> 	I do agree with your goal, however, to indicate that this
> 	mechanism is for integrity only.

Understandable.  We might have to review/discuss all the 2119 words in the
document individually, as painful as that may be.

> 	**It says "Since error-detection support is mandatory, this means
> 	that the minimal BSP elements that all Bundle Protocol implementations
> 	MUST support include: ...".  I don't believe this document introduced
> 	what would be mandatory or not, so I was suprised to find it
> 	listed here.  At one point we had agreed that "mandatoriness", in
> 	terms of significant capabilities, would be defined in separate
> 	RFCs.  Following along these lines, I believe this document
> 	should just define the various ways of doing things, and whether
> 	its mandatory or not should be deferred to a separate conversation.

Ok.  Some of the above comments on making it clear what claims
bundling does or does not make on data integrity for apps fit
here too.  Again, I'm fine with whatever we decide as long as it's
abundantly clear in the deliverables.

> 	**Given the general approach here is to use existing forms of
> 	transformations with NULL keys, maybe it would be sensible to
> 	just establish an INSECURE bit that is orthogonal from the
> 	transofrmations, to indicate a NULL key.

Seems logical.

> 	The comment that MD5 can be executed 2x faster than SHA1 should
> 	include a reference to the mentioned "benchmarking activities".

That's easy to do, though any numbers pertain to specific implementations
and specific platforms, so I was hesitant, especially since I think the
performance difference between the two is well-understood.

> 	It might also be worth mentioning that there is now a loss
> 	of faith in the efficacy of MD5 for security purposes, but that
> 	fact doesn't diminish its utility for this purpose.

Ok, and the difference between MD5 and HMAC-MD5 is relevant here as well.

> 	** I see the use of some of the specified capabilities are
> 	tied together with custody transfer.  I'm not sure that
> 	is the best thing.  Rather it may make more sense to have
> 	the concept of "discard if errorful" a more general
> 	class of service or option to the sender, orthogonal from
> 	custody transfer, as I think you begin to describe on page 13.
> 	Why not take this approach in the current document?  We don't
> 	need to re-issue the bundle protocol spec for it.  This might
> 	also mesh nicely with the earlier comment above regarding
> 	the 'insecure' flag.  This should be discussed I think.

Interesting idea.

> 	The paragraph starting with "This design decision" and
> 	the following one, starting with "Ideally" needs to be
> 	in a separate 'rationale' document, if you care to write one.
and
> 	The paragraph starting with Using the same" needs to be
> 	in a separate 'rationale' document, if you care to write one.

*I* don't care to write one :).  To be blunt and maybe a little daft,
I'd like to get a reasonable bolt-on for providing error-detection done
as quickly as possible so I can concentrate on more interesting and
innovative things in DTN. (and I doubt many would care to read such a
rationale document!)  This stuff is pretty tedious, for me at least, in
comparison to the projects that originally drew our attention to this
side-issue.

> 	**I specifically object to the phrase:
> 	    It is well-understood that future revisions
> 	    of the Bundle Protocol need to include appropriate checksums within
> 	    the basic format of each block.
> 
> 	for the reasons mentioned above.  I do not object to the portion
> 	that starts with "In order to limit overhead..."

Ok, this goes back to the "is it clear that the bundle protocol / DTN
architecture requires apps to be careful about bit errors and
misdelivery?" We should consolidate that discussion to a single point
(maybe it's own thread?) to follow-up.

Cc: dtn interest <[email-masked]>
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Date: Tue, 18 Sep 2007 13:01:35 -0700
To: Peter Lovell <[email-masked]>
Sender: [email-masked]

I believe what we had settled on was the idea that you can have a  
document that specifies something that is or is not required (by some  
other doc), but that if it is used, there can be MUSTs.  That may  
sound confusing, but what I mean is that you can define something  
like bundle security such that if security is used then the MUSTs  
have to be implemented.

The checksum document as written requires -all- bundle  
implementations to include the proposed functionality.  I wanted to  
red-flag that item, because  in some (most?) of the scenarios to  
date, this functionality was not required or deemed necessary.  If we  
collectively really believe this to be critical at this point then we  
can impose the requirement that all implementations do it, but at  
some level I would prefer to just describe the capability in detail,  
and leave it to another document to define which RFCs are to be  
implemented in order to achieve what results.  Even this way we could  
issue an RFC that says 'the bundle protocol now means RFCxxx and  
RFCyyy to be compliant'  (whatever it means to be compliant to an  
experimental protocol is arguable, but nevertheless).  This mimics  
the way the host requirements RFC worked, or what at least was the  
occasional list of 'standard' rfcs.

- K

On Sep 18, 2007, at 12:30 PM@Sep 18, 2007, Peter Lovell wrote:

> Hi Kevin,
>
> On Tue, Sep 18, 2007, Kevin Fall <[email-masked]> wrote:
>
>> please see attached.  The items with "**" in front of them may have
>> larger implications than those that don't.
>>
>> - K
>
> and one of the ** sections is ...
>
>  **It says "Since error-detection support is mandatory, this means
> 	that the minimal BSP elements that all Bundle Protocol  
> implementations
> 	MUST support include: ...".  I don't believe this document introduced
> 	what would be mandatory or not, so I was suprised to find it
> 	listed here.  At one point we had agreed that "mandatoriness", in
> 	terms of significant capabilities, would be defined in separate
> 	RFCs.
>
>
> At the moment, the Bundle Security Protocol spec does have some
> statements on mandatoriness, specifically that three particular
> ciphersuites MUST be implemented (if you implement BSP at all, that  
> is).
>
> In light of your comment, is that a correct thing to say in the BSP
> spec? I don't have a specific issue either way - it's just that I  
> don't
> want to keep it in the spec if it had been decided that we shouldn't.
>
> Thanks.....Peter
>
>

From: "Peter Lovell" <[email-masked]>
To: "Kevin Fall" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re: [dtn-interest] comments on checksum draft
Date: Tue, 18 Sep 2007 15:30:23 -0400
Sender: [email-masked]

Hi Kevin,

On Tue, Sep 18, 2007, Kevin Fall <[email-masked]> wrote:

>please see attached.  The items with "**" in front of them may have  
>larger implications than those that don't.
>
>- K

and one of the ** sections is ...

 **It says "Since error-detection support is mandatory, this means
	that the minimal BSP elements that all Bundle Protocol implementations
	MUST support include: ...".  I don't believe this document introduced
	what would be mandatory or not, so I was suprised to find it
	listed here.  At one point we had agreed that "mandatoriness", in
	terms of significant capabilities, would be defined in separate
	RFCs.  

At the moment, the Bundle Security Protocol spec does have some
statements on mandatoriness, specifically that three particular
ciphersuites MUST be implemented (if you implement BSP at all, that is).

In light of your comment, is that a correct thing to say in the BSP
spec? I don't have a specific issue either way - it's just that I don't
want to keep it in the spec if it had been decided that we shouldn't.

Thanks.....Peter

To: DTN interest <[email-masked]>
From: Kevin Fall <[email-masked]>
Date: Tue, 18 Sep 2007 12:04:43 -0700
Subject: [dtn-interest] comments on checksum draft
Sender: [email-masked]

--Apple-Mail-19--765797961
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

please see attached.  The items with "**" in front of them may have  
larger implications than those that don't.

- K
--Apple-Mail-19--765797961
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	x-unix-mode=0644;
	name=cksum-comments.txt
Content-Disposition: attachment;
	filename=cksum-comments.txt

comments on draft-irtf-dtnrg-bundle-checksum-00.txt of Aug 2007

K. Fall, Sep 2007

Abstract
	remedies -> addresses
	heavy-weight (delete)

	"expense of divorcing security concerns from the few new ciphersuite
	definitions" seems a bit out of context... what does this
	really mean?  (in particular, what does "few" and "new" refer to)

	lengthily (delete)

Section 1:

	the statement:

	  It is assumed that the "convergence layer adapters" that connect
	  BAs to each other will detect and correct errors before presenting
	  bundle data to the BAs themselves.

	is not quite correct.  While some people might hope that is true,
	and it indeed might often be true, a more accurate statement would
	say something like 'those applications requiring data integrity are
	responsible for implementing their own data checking functions'.
	It might also be useful to refer to the effect of the security
	mecanisms at this point that accomplish the same.

	On what basis is it 'statistically likely' that transmission errors
	will go unnoticed or unchecked errors will be introduced within
	a BA's memory/storage/forwarding systems?  More specifically, for
	errors that could be addressed by checksums (mostly bit type errors),
	can you provide a modern reference to support this assertion?  The
	paragraphs that you have as examples are fine as to why this the
	bit errors -can- happen, any I would agree motivate the work, but
	they do not argue that these types of errors -are likely- to happen
	and be uncorrected.

	I like the writing of the paragraph ending section 1.

Section 2

	"pressed into use" -> "used"

	In 2.1 you argue the length bundle produced using SHA-256 for
	data integrity is not attractive, especially for small bundles.  
	If you could provide example(s) that would make this point clearer
	and you can use it compare against the proposed mechanism.

	The "bulk of code" argument I don't really find very compelling,
	given the forward progress of computer systems and the amount
	of code already required to do all of the other things.  If I were
	writing this document, I might mention this issue as a sort of
	aside, along the lines of "in some [e.g. embedded] systems, the
	implementation complexity of RSA can be significant.... blah blah"

Section 3

	The phrase: "Since error-detection and rejection is a vital
	and absolutely essential component of reliable networking protocols"
	I don't necessarily agree with.  This refers to what layer you
	implement this capability, and as mentioned above, the application
	is free to implement this and in general we advise folks to
	implement apps this way if they require it.

	"labelled" I believe should be "labeled"

	I'm not comfortable with the use of MUST where the accompanying
	compliance criteria involves the words "sufficiently dissimilar"
	and MUST NOT with "leads to their being construed as".  I believe
	this criteria is too subjective to be used with MUSTs.   Note that
	I do agree with your goal, however, to indicate that this
	mechanism is for integrity only.

	**It says "Since error-detection support is mandatory, this means
	that the minimal BSP elements that all Bundle Protocol implementations
	MUST support include: ...".  I don't believe this document introduced
	what would be mandatory or not, so I was suprised to find it
	listed here.  At one point we had agreed that "mandatoriness", in
	terms of significant capabilities, would be defined in separate
	RFCs.  Following along these lines, I believe this document
	should just define the various ways of doing things, and whether
	its mandatory or not should be deferred to a separate conversation.

	**Given the general approach here is to use existing forms of
	transformations with NULL keys, maybe it would be sensible to
	just establish an INSECURE bit that is orthogonal from the
	transofrmations, to indicate a NULL key.

	The comment that MD5 can be executed 2x faster than SHA1 should
	include a reference to the mentioned "benchmarking activities".
	It might also be worth mentioning that there is now a loss
	of faith in the efficacy of MD5 for security purposes, but that
	fact doesn't diminish its utility for this purpose.

	for the CRC32 variant, you say it MUST only be used on bundles
	with payload length < 64k.  Why this restriction?  If you
	use the "standard" polynomial for CRC32 you get any 1 or 2
	bit errors up to 4GB [Boudreau et al, 1994].
	(Aside: the paper Ray, Koopman
		"Efficient High Hamming Distance CRCs for Embedded Networks"
		(DSN June 2006) may be of interest to you)

	In 3.1 there is another discussion of what MUST be implemented.
	Please see earlier comment regardin MUSTs.
	Also, typo: "teh" -> "the"

	** I see the use of some of the specified capabilities are
	tied together with custody transfer.  I'm not sure that
	is the best thing.  Rather it may make more sense to have
	the concept of "discard if errorful" a more general
	class of service or option to the sender, orthogonal from
	custody transfer, as I think you begin to describe on page 13.
	Why not take this approach in the current document?  We don't
	need to re-issue the bundle protocol spec for it.  This might
	also mesh nicely with the earlier comment above regarding
	the 'insecure' flag.  This should be discussed I think.

Section 4

	The paragraph starting with "This design decision" and
	the following one, starting with "Ideally" needs to be
	in a separate 'rationale' document, if you care to write one.

	**I specifically object to the phrase:
	    It is well-understood that future revisions
	    of the Bundle Protocol need to include appropriate checksums within
	    the basic format of each block.

	for the reasons mentioned above.  I do not object to the portion
	that starts with "In order to limit overhead..."

	The paragraph starting with Using the same" needs to be
	in a separate 'rationale' document, if you care to write one.

Section 5

	Didn't you specify new codepoints for ciphersuites?

Section 6

	remove "limitations of", unless you are intending to
	specifically document them

--Apple-Mail-19--765797961--

From: Michael Demmer <[email-masked]>
Date: Mon, 17 Sep 2007 16:26:17 -0700
To: [email-masked], dtn-interest <[email-masked]>
Subject: [dtn-interest] cleanup of old routing modules
Sender: [email-masked]

Hi all,

The DTN reference implementation has two old routing implementations  
-- LinkStateRouter and NeighborhoodRouter -- that have not been  
maintained for some time now. Furthermore, the features of those two  
routers have been largely superceded by our recent work on Delay  
Tolerant Link State Routing (DTLSR) [1].

If no-one responds indicating that they're using these routers, I'd  
like to remove them from the reference implementation before the next  
release.

-mike

[1] http://www.cs.berkeley.edu/~demmer/papers/dtlsr-nsdr07.pdf

Date: Tue, 18 Sep 2007 00:13:03 +0100
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
CC: Kevin Fall <[email-masked]>, DTN interest <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTNRG meeting missing from IETF proceedings
Sender: [email-masked]

Lloyd Wood wrote:
> Kevin,
> 
>> I believe you will find that despite occasional late postings of  
>> minutes and other process matters, this is one of the more productive  
>> and effective IRTF groups.
> 
> How do we measure productivity and effectiveness? 

Certainly not by the amount of vituperation, which seems to be highly
correlated with your postings.

Perhaps someday you'll figure out how to make your points politely and
reasonably. So far, you clearly have not. And as I said on this list a
few months ago, your constant unpleasantness makes me and others
discount almost everything you say.

 > I also see that in recent list discussion of bundle security Stephen
 > Farrell has remarked that the approach to specifying ciphersuites for
 > payloads is "a bit broken".

That's taken entirely out of context. If you only want to be
argumentative then this isn't the place. (And nor apparently are you
that good at it - annoying the audience is a sure way of losing any
debate. Not realising that you've done that would be worse, so I
guess I have to assume you do it deliberately.)

Regardless, if you can limit yourself to making reasoned arguments,
I'll be glad to react to those. If not, not.

S.

Date: Mon, 17 Sep 2007 22:10:51 +0100
To: Kevin Fall <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] DTNRG meeting missing from IETF proceedings
Cc: DTN interest <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Kevin,

>I believe you will find that despite occasional late postings of  
>minutes and other process matters, this is one of the more productive  
>and effective IRTF groups.

How do we measure productivity and effectiveness? On number of drafts issued and adopted?

>Note that this productivity seemed to be  
>going along just fine prior to your participation, without  
>significant complaints.  Hopefully that can continue with your  
>participation, although I'm not sure.  Your suggestion that the  
>protocol designs are 'weak' in some absolutist sense is way out of line.

At the Chicago meeting we discussed lack of any error detection and protection in the bundle and Licklider protocols and their lack of robustness in accordance with the end-to-end principle.

In fact, we've written draft-eddy-dtnrg-checksum-00 and the just-submitted draft-irtf-dtnrg-bundle-checksum-00 as two separate approaches to addressing this recognised weakness - though, given the current design of the bundle protocol, those drafts recognise that this weakness cannot be fully addressed without some major protocol changes. This is a documented and described weakness in how the bundle protocol can receive corrupted data, without ever recognising that it has done so. That weakness alone - that you can't know that what was sent isn't what was received - justifies my observation.

I also see that in recent list discussion of bundle security Stephen Farrell has remarked that the approach to specifying ciphersuites for payloads is "a bit broken".

(It's certainly okay for experimental protocols intended for research to be weak in various areas, as that's part and parcel of exploring new ideas and learning what works and what doesn't. But the need to ensure reliability and protect against introduced errors is fundamental, and is not a new research issue. I would be very sceptical about taking the bundle protocol - an experimental protocol - as is for use in a production environment. How error prevention and mutability are approached needs a rethink imo, and this will affect security too.)

L.

>- K

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 

Date: Mon, 17 Sep 2007 21:44:13 +0100
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
CC: Lloyd Wood <[email-masked]>, DTN interest <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTNRG meeting missing from IETF proceedings
Sender: [email-masked]

What Kevin said. (What I said when I saw that mail is unprintable,
luckily none of you heard that though:-)

S.

Cc: DTN interest <[email-masked]>, [email-masked], [email-masked]
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] DTNRG meeting missing from IETF proceedings
Date: Mon, 17 Sep 2007 13:20:04 -0700
To: Lloyd Wood <[email-masked]>
Sender: [email-masked]

On Sep 17, 2007, at 12:38 PM@Sep 17, 2007, Lloyd Wood wrote:

> I see that the IETF 69 Chicago meetings have now been published:
> http://www3.ietf.org/proceedings/07jul/index.html
> replacing the temporary list of materials that was at:
> https://datatracker.ietf.org/meeting/69/materials.html
>
> Proceedings of the DTN research group are absent from the IETF 69  
> proceedings, unlike all the other research groups that met in  
> Chicago, which have both presentation slides and minutes.
>
> Although DTNRG presentations were collected and made available on  
> the temporary datatracker page, these have not made it through to  
> the final proceedings. Although I heard one of the DTN chairs check  
> that notes were being taken at the start of the meeting, no minutes  
> or draft minutes have been circulated from that meeting. Minutes  
> are needed so that everyone who attended can agree on what was  
> concluded, and so that those who weren't there can find out -  
> rather than things being forgotten. The fact that e.g. Tom  
> Henderson presented on ns3 to the DTN research group, or that we  
> discussed deficiencies in the bundle protocol design and what could  
> and should be done about them, is not visible anywhere.
>
> The DTNRG chairs have missed previous deadlines related to this  
> meeting [1] [2], so it's possible that a deadline for uploading  
> final material (due 12 September) was missed as well. The deadlines  
> for draft minutes and final minutes were certainly missed.
>
> I feel that the DTN research group is not being run effectively (as  
> might be reflected in the weak protocol designs that have resulted,  
> which our team has expended a lot of time and effort on in  
> suggesting fixes to) and that better, competent and attentive,  
> stewardship of this research group, to at least follow the process  
> and document the group's activities with timely minutes, is sorely  
> needed.

I believe you will find that despite occasional late postings of  
minutes and other process matters, this is one of the more productive  
and effective IRTF groups.  Note that this productivity seemed to be  
going along just fine prior to your participation, without  
significant complaints.  Hopefully that can continue with your  
participation, although I'm not sure.  Your suggestion that the  
protocol designs are 'weak' in some absolutist sense is way out of line.

- K

Date: Mon, 17 Sep 2007 20:38:48 +0100
To: DTN interest <[email-masked]>
From: Lloyd Wood <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] DTNRG meeting missing from IETF proceedings
Sender: [email-masked]

I see that the IETF 69 Chicago meetings have now been published:
http://www3.ietf.org/proceedings/07jul/index.html
replacing the temporary list of materials that was at:
https://datatracker.ietf.org/meeting/69/materials.html

Proceedings of the DTN research group are absent from the IETF 69 proceedings, unlike all the other research groups that met in Chicago, which have both presentation slides and minutes.

Although DTNRG presentations were collected and made available on the temporary datatracker page, these have not made it through to the final proceedings. Although I heard one of the DTN chairs check that notes were being taken at the start of the meeting, no minutes or draft minutes have been circulated from that meeting. Minutes are needed so that everyone who attended can agree on what was concluded, and so that those who weren't there can find out - rather than things being forgotten. The fact that e.g. Tom Henderson presented on ns3 to the DTN research group, or that we discussed deficiencies in the bundle protocol design and what could and should be done about them, is not visible anywhere.

The DTNRG chairs have missed previous deadlines related to this meeting [1] [2], so it's possible that a deadline for uploading final material (due 12 September) was missed as well. The deadlines for draft minutes and final minutes were certainly missed.

I feel that the DTN research group is not being run effectively (as might be reflected in the weak protocol designs that have resulted, which our team has expended a lot of time and effort on in suggesting fixes to) and that better, competent and attentive, stewardship of this research group, to at least follow the process and document the group's activities with timely minutes, is sorely needed.

thanks,

L.

[1] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-May/002715.html
[2] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-July/002763.html

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>  

From: "Peter Lovell" <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "dtn interest" <[email-masked]>
Date: Mon, 17 Sep 2007 14:22:02 -0400
Subject: [dtn-interest] discussion-draft-04f
Sender: [email-masked]

--==_20070917182202.1292926417-1_==
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I am in the process of revising the BSP draft and plan to finish this
cycle this week.

Before submitting it, though, I want to circulate it once for comment,
especially because there are some substantial changes.

To help with this, I'm including a diff against the -03 version which is
the "current" one with IETF.

In brief summary, the changes are ...
- consistency in diagram labeling [minor]
- use of the term "security zone" [minor]
- more exact use of "EID reference" [minor]
- ciphersuite ID and flags are SDNVs [several changes]
- support for ciphersuite IDs > 127 is optional, not required
- flags are right-adjusted, relabeled
- "payload excess" is removed, discussion changed [substantial]
- distinguish between "fragment" and "partial protection" [minor]
- discuss means for either of above
- strong recommendation to use authentication with encryption
- strong recommendation to not change payload length
- description tightening and more details for confidentiality [substantial]-
- item types added in section 2.5 [major]
- PEP discussion clarified [minor]
- add section on order-of-processing and security zones [major]
- rework some discussion of mutable canonicalization
- remove fragment-offset-and-length from canonicalization
- "receiving node's own endpoint" stuff deleted [several places]
- discussion related to fragmentation clarified in section 3.7 [minor]
- rewrite of C3 section 4.3 [major]

Please get comments to me by COB Wednesday so I can incorporate them
into the draft for submission.

Thanks.....Peter
--==_20070917182202.1292926417-1_==
Content-Type: multipart/mixed; boundary="==_20070917182202.1292926417-2_=="

--==_20070917182202.1292926417-2_==
Content-Type: text/html;
 name="discussion-draft-04f-from-raft-irtf-dtnrg-bundle-security-03.diff.html"
 ; x-mac-type="00000000"; x-mac-creator="00000000"
Content-Disposition: attachment
Content-Transfer-Encoding: base64

--==_20070917182202.1292926417-2_==
Content-Type: text/plain; name="discussion-draft-04f.txt";
 x-mac-type="00000000"; x-mac-creator="00000000"
Content-Disposition: attachment
Content-Transfer-Encoding: base64

--==_20070917182202.1292926417-2_==--
--==_20070917182202.1292926417-1_==--

To: DTN interest <[email-masked]>
From: Kevin Fall <[email-masked]>
Date: Sat, 15 Sep 2007 18:48:32 -0700
Subject: [dtn-interest] Fwd: [Ns-developers] ns-3.0.6 development release available
Sender: [email-masked]

--Apple-Mail-16--1000768038
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

cross-posting for the interested... -=K

Begin forwarded message:

> From: Tom Henderson <[email-masked]>
> Date: September 15, 2007 3:29:46 PM PDT  Sep 15, 2007
> To: ns-developers <[email-masked]>
> Subject: [Ns-developers] ns-3.0.6 development release available
>
> The most recent of our monthly ns-3 development releases is  
> available at the below location:
> http://www.nsnam.org/releases/ns-3.0.6.tar.bz2
>
> Please see this "getting started" page:
> http://www.nsnam.org/getting_started.html
>
> From the release notes:
>
> Release 3.0.6 (2007/09/15)
> ========================
>   - Static multicast IPv4 routing
>   - Logging overhaul (NS_LOG macros)
>   - Refactoring of tracing subsystem
>   - Tutorial document started
>
> Credit is due to Craig Dowell for implementing the multicast  
> routing, to Mathieu Lacage for doing additional work on the tracing  
> subsystem, and to both Craig and Mathieu for improving the logging  
> subsystem.  Craig has also started work on a tutorial, which I'll  
> add to our documentation page within the next two days.
>
> The next regularly scheduled release is in mid-October.  We'll  
> update the roadmap again in about a week and update the list.  This  
> wiki page is also being used to keep track of proposals under review:
> http://www.nsnam.org/wiki/index.php/ 
> Roadmap#Code_proposals_under_review
>
> Please post feedback on the design and/or roadmap, and please email  
> one of the developers if you are interested in working on something  
> for ns-3, whether it is already listed on the roadmap or not.
>
> - Tom
>
>
>

--Apple-Mail-16--1000768038
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">cross-posting for the =
interested... -=3DK<BR><DIV><BR><DIV>Begin forwarded message:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>From: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Tom Henderson &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>Date: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">September 15, 2007 3:29:46 PM PDT<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>Sep 15, 2007</FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>To: </B></FONT><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">ns-developers &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FONT>=
</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" =
color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Subject: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><B>[Ns-developers] ns-3.0.6 development =
release available</B></FONT></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV> <DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">The most recent of our monthly =
ns-3 development releases is available at the below location:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"http://www.nsnam.org/releases/ns-3.0.6.tar.bz2">http://www.nsnam.o=
rg/releases/ns-3.0.6.tar.bz2</A></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Please see this "getting =
started" page:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://www.nsnam.org/getting_started.html">http://www.nsnam.org/ge=
tting_started.html</A></DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">=46rom the release =
notes:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Release 3.0.6 (2007/09/15)</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>- Static multicast IPv4 =
routing</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>- Logging overhaul (NS_LOG =
macros)</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>- Refactoring of tracing =
subsystem</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>- Tutorial document =
started</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Credit is due to Craig Dowell for implementing the =
multicast routing, to Mathieu Lacage for doing additional work on the =
tracing subsystem, and to both Craig and Mathieu for improving the =
logging subsystem.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>Craig =
has also started work on a tutorial, which I'll add to our documentation =
page within the next two days.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">The next regularly scheduled =
release is in mid-October.<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>We'll update the roadmap again in about a week and update the =
list.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>This wiki page is =
also being used to keep track of proposals under review:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"http://www.nsnam.org/wiki/index.php/Roadmap#Code_proposals_under_r=
eview">http://www.nsnam.org/wiki/index.php/Roadmap#Code_proposals_under_re=
view</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Please post feedback on the design and/or roadmap, =
and please email one of the developers if you are interested in working =
on something for ns-3, whether it is already listed on the roadmap or =
not.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">- Tom</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> =
</BLOCKQUOTE></DIV><BR></BODY></HTML>=

--Apple-Mail-16--1000768038--

Date: Fri, 07 Sep 2007 14:09:02 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] IESG approved BP spec...
Sender: [email-masked]

FYI. The IESG yesterday ok'd the bp spec. [1] It'll now
go to the RFC editor.

S.

[1] https://datatracker.ietf.org/idtracker/draft-irtf-dtnrg-bundle-spec/

Date: Wed, 05 Sep 2007 09:30:20 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] IETF 70 in vancouver
Sender: [email-masked]

All,

As discussed in Chicago we don't plan for DTNRG to meet at
IETF 70 in Vancouver, so we'll probably meet at the following
IETF:

Spring 2008 - 71st IETF
         March 9-14, 2008
         Host: Comcast
         Location: Philadelphia, PA, USA

If you think we need a meeting in the meantime let Kevin and I
know,

S.