Re: [dtn] IPND draft 03 remarks

[Carlo Caini <[e-mail]>]

Dear Sebastian,
   I am not active on the draft, but I have used ipnd on both IBR-DTN for Android 1.0 , and also in ION (ipnd is in 3.4.0, just released).
I have only a brief comment on 2.6. I would not be enthusiast of keeping coupled the versioning of two different protocols, ipnd and BP. In general, it is always better to decouple things, to make easier their maintenance. Now the situation is moving, as you said, so now this is not a problem. Tomorrow, in case of any new version of BP (in iETF)  we should change also the version of ipnd (maybe still in IRTF?). Why not to decouple them, by introducing a field devoted to BP version separate by that of ipnd? 
Last but not least, in my opinion ipnd is an essential component of the DTN architecture, so I am grateful to you and to all researchers that have devoted their effort to its definition and implementation.
Yours,
  Carlo




________________________________________
Da: dtn [[e-mail]] per conto di Sebastian Schildt [[e-mail]]
Inviato: sabato 23 gennaio 2016 22.38
A: [e-mail]
Oggetto: [dtn] IPND draft 03 remarks

Hello,

I am not sure if this is the right group to discuss IPND (dtnrg seems to have vanished completely? At least the webpage), but since it has been mentioned in the last interim I will post it here.

I just had a quick look, and here are some initial remarks

> 2. Protocol Description
> Nodes use DTN IPND beacons, small UDP messages in the IP underlay, to advertise presence

Since the IPND format is quite generic, I would not limit it to UDP. In fact, we have used earlier versions of the draft on 802.15.4.  While not all possibilities can and should be spelled out in the IPND draft, maybe at least the introduction should be more open.
When really defining details how to use IPND on different convergence layers (such as specific UDP Port, or how the represent CL addresses in Beacons) the question is, would we consider this extensions of this Draft, or addon-Drafts "Using IPND over <magic transport>"?


> 2.6.  Beacon Message Format
>  o  Version: An 8-bit field indicating the version of IPND that
>     constructed this beacon.  The present document describes version
>     0x04 of IPND.  This version field is incremented for IPND if
>     either the IPND protocol is modified or the Bundle Protocol
>     version is incremented.
Good idea to use this to determine the BP version directly in the beacon. However, this does only make sense if the draft clearly states WHICH BP version corresponds to IPND 0x04 :) (since this is still in draft state, no problem if rfc5050bis is also a moving target, we can always change the IPND draft to follow draft-ietf-dtn-bpbis)


> 2.6.4.  Neighborhood Bloom Filter
I am not sure I get it completely, maybe should be rewritten for clarity. But I am quite sure there is not enough information to really get the correct parameters for the BF. The data structure in the beacon should explicitly give the number of hash functions and the length of the BF (that is a given due to the TLV encoding). Then the IPND document should describe an unambiguous way, how to generate k hash functions. I do not have a detailed plan for this, but just from the top of my head: Something like SHA-1 (ubiquitous hardware acceleration, good distribution, cryptographic security irrelevant) salted differently and take the first bits. (Or some slicing, however slicing is dangerous, becasue then you cannot support arbitrarily long BFs). If we want this to work an small microcontrollers, probably a simpler hash than SHA1 would be needed, however than we really need to choose well, to make sure it is robust against collusion. Many "simple, just 10 lines of C"-kind of hashes make compromises. By choosing an established cryptographic hash,  we can be sure it is a very solid general hashing function (even MD5 would be perfectly fine).


I am not sure how many people are actively working on the draft (but I suggest they are all reading this list :) ) . If it helps I can also (with a couple of days delay) propose some text addressing the issues mentioned.


Sebastian