Re: [dtn] DTN TCPCL and contact EID

[Brian Sipos <[e-mail]>]

Carlo,

Thank you for the information on this use case.


This brings up a more fundamental issue than this CL in particular. When we had been reviewing BPbis earlier in the year we had come to consensus about not putting any more specific CL requirements in BP itself but somewhere, somehow within a CL BCP document. This would distinguish what a CL should do, but just as importantly what it should not do.


At the very least, I know that a BP CL running directly on LTP will not be able to provide this kind of EID discovery, but then again LTP is (maybe?) more likely to be used in a fixed-routing network. Even in the last revision of IPND draft <https://tools.ietf.org/html/draft-irtf-dtnrg-ipnd-03> there is a section 2.7 which basically says of DTN CLs and discovery that (paraphrasing) "maybe they do and maybe they don't."

________________________________
From: Carlo Caini <[e-mail]>
Sent: Sunday, October 2, 2016 2:00:04 PM
To: Brian Sipos; [e-mail]
Subject: RE: DTN TCPCL and contact EID

Dear Brian,
   Although I have not any TCPCL implementation experience, I have some experience dealing with TCPCL in ION, DTN2 and more recently also on IBR-DTN, and I would like to share my view with you.
I would say that the EID is necessary, while I am basically neutral about fixed or SDNV (not enough knowledge to provide you with a reasonable opinion). I think that is necessary, at least in a few situations, in order to perform the late binding, i.e. the association between the DTN EID (BP layer) and the IP address (network layer). it may happen that a node (e.g. nodeA) wants to get in contact via TCPCL with another node (nodeB), of which it knows the IP (but not vice versa). Node A can launch a TCP connection towards nodeB; nodeB will discover the association EID-IP of nodeA when the TCP connection is established, thanks to the EID field. Node B could be a node with a fixed IP address, while node A  could have a dynamic address (thus node B cannot know the IP address of A in advance). I used this many times in DTN2.
Discovery could be useful if nodeA and nodeB belonged to the same local network, because discovery packets are generally sent in local broadcast. To send a discovery packet to nodeB, if nodeB were on another network, would require a change in the discovery settings to point to the specific address of nodeB (you cannot flood the whole Internet with discovery packets), which seems to me quite impractical. Moreover, discovery is an ancillary mechanism, which can be present or not, while late binding is essential to BP.
Security may be an issue, because nodeC could disguise himself as nodeA, but I think that the solution it is not to remove the EID.

Yours,
  Carlo
________________________________________
Da: dtn [[e-mail]] per conto di Brian Sipos [[e-mail]]
Inviato: domenica 2 ottobre 2016 17:42
A: [e-mail]
Cc: Burleigh, Scott C (312B); Joerg Ott
Oggetto: [dtn] DTN TCPCL and contact EID

All,

I'm sending this to the entire mailing list, but asking for any specific feedback from those with TCPCLv3 implementation experience (I know at least Joerg O. and Scott B. have).

After the interim meeting last week I've started in on prototyping a simplified TCPCLv4 contact header with fixed-length fields. The only remaining non-fixed-length element (excluding data segments themselves) appears to be the contact header EID text-string.


My question is this: Is there any value in actually having the EID in a contact header? As Joerg mentioned in the meeting, this is something which could be handled at a higher level (i.e. DTN AMP) or at a lower level (i.e. neighbor discovery). And the EID itself is a non-authoritative value on an unsecured TCP connection, so I personally do not see any value in keeping this around in TCPCLv4. If it was kept in, it would be the only use of SDNV-type length field in TCPCLv4 so removing it would save on complexity.


Any WG thoughts on removing the EID exchange?

Thanks,

Brian