Re: [dtn] IPND draft 03 remarks

[Sebastian Schildt <[e-mail]>]

Hello Carlo,

> On 23 Jan 2016, at 23:22, Carlo Caini <[e-mail]> wrote:

> 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? 
> 

Yes, I think you are right. Instead of adding a separate field, the existing 8bit field can be used for it (because overhead is important for beacons): If the first 4 bits define the IPND version and an „offset“ for the BP version, the second 4bit can define BP version. This will then also work in the unlikely case we run out of space when using only 4 bit do identify BP version:

e.g in IPND:
0x47    -> IPND v4, BP v7
in the (far) future possibly
0x62   -> IPND v6 defines BP version offset is 32, so 2 identifies BP protocol version 34 



Sebastian






> 
> 
> ________________________________________
> 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 c
> ompromises. 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
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn