Re: [dtn] DTN TCPCL and contact EID

["Burleigh, Scott C (312B)" <[e-mail]>]

Sorry to be responding so late - it has unfortunately taken me all this time to bubble this thread to the top of my to-do list.  I don't think leaving node identification to a higher layer of the stack is practicable, since AMP messages (for example) are carried in bundles whose destinations are identified by BP EIDs, which is exactly the information that is missing.  But I think leaving it to whatever mechanism is used to do local node configuration management - whether neighbor discovery or some sort of local administrative utility - might be okay.

The ID of the socket from which the contact header was transmitted is potentially dynamic, hence not informative.  But maybe we can assert that any node that issues a contact header is required to be listening for inbound connections (contacts from other nodes) on some static IP address and port number.  That reception socket ID could be something that neighbor discovery (or, alternatively, a local node administration utility) could associate with a BP EID in the configuration database of the node that receives the contact header, ahead of time and out of band.  Then if the contact header contained the reception socket ID of the contacting node (which would be fixed-length data), the receiving node could look that socket ID up in its own configuration database and associate the received contact with the sending node's BP EID.

Scott

From: dtn [mailto:[e-mail]] On Behalf Of Brian Sipos
Sent: Sunday, October 2, 2016 4:34 PM
To: Carlo Caini <[e-mail]>; [e-mail]
Subject: Re: [dtn] DTN TCPCL and contact EID


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]<mailto:[e-mail]>>
Sent: Sunday, October 2, 2016 2:00:04 PM
To: Brian Sipos; [e-mail]<mailto:[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]<mailto:[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