Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

From: Brian Sipos <[email-masked]>
Date: Thu, 8 Aug 2019 21:18:19 +0000

All,
Because I am less familiar with the nuances of preexisting DTN and TCPCLv3 uses, can anyone help inform me about how the EID was/is intended to be used as part of the TCPCL. As Magnus points out, as currently written (and as a carry-over from TCPCLv3) there is no mechanism to authenticate that the EID sent by a TCPCL Entity is properly bound to the host sending it. Is there a purpose for this EID other than manual troubleshooting?

I'm planning on adding some text explaining how TLS with X.509can be used to authenticate the TCPCL peer based on the hostname/address used for the TCP connection in accordance with RFC 6125. It would also be possible to authenticate the EID as a subject URI of a peer certificate. Does this seem reasonable and desirable?

Thanks for any guidance,
Brian S.

________________________________
From: Magnus Westerlund
Sent: Thursday, August 01, 2019 09:31
To: [email-masked]; [email-masked]
Subject: AD review of draft-ietf-dtn-tcpclv4-12

Hi,

I have now performed my AD review of draft-ietf-dtn-tcpclv4-12. I think most are minor comments, however the TLS and security related ones may be more problematic to resolve. I will now be on vacation so you know you will not receive any quick replies from me before the end of the month.

  1.  Section 1: What are the applicability of TCPCLv4 to BPv6? I wonder as RFC5050 is referenced.

  2.  Section 1.1: Session State Changed. Some editorial issues. Missing “:” initially. Then double “..” on Terminated.

  3.  Section 1.1:
   Session Idle Changed  The TCPCL supports indication when the live/idle sub-state changes.  This occurs only when the top-level session state is Established.  Because TCPCL transmits serially over a TCP connection, it suffers from "head of queue blocking" this indication provides information about when a session is available for immediate transfer start.

So in which direction are this change indicated/reported, both or only in one of them, or any as implied by Section 2.1’s definition of Live Session?

  4.  Section 1.1: Transmission Intermediate Progress: Segment is not defined prior to this. Maybe a forward pointe? Or should maybe the whole subsection (1.1) be moved to after definitions?

  5.  Section 2: Is there a point to use the RFC 8174 language that makes only capital words have special meaning?

  6.  Section 3.1: “One of these parameters is a singleton endpoint identifier for each node (not the singleton Endpoint Identifier (EID) of any application running on the node) to denote the bundle-layer identity of each DTN node.”

The above quote does imply something that at least BPBis isn’t making clear that a particular application agent would have its own EID. It is not clear that there are a one-to-one relationship between bundle nodes and application agents. Can you please clarify what the relationship is and lets figure out if that needs to be clarified back to BPbis.

  7.  Section 3.1: “Bundle interleaving can be accomplished by fragmentation at the BP layer or by establishing multiple TCPCL sessions between the same peers.”

Are there clear rules established for how many TCPCL sessions in parallel that may be established? By the end of my reading this is unanswered.

  8.  Section 3.1: XFER_REFUSE does that indicate that the bundle has already been received. How else does one separate other reasons for refusing a bundle versus that one have received it prior?

  9.  Section 3:1:    Once a session is established established, TCPCL is a symmetric protocol between the peers.
Double established

  10. Figure 4: “Close message” is this TCP level message, if that is the case can that be clarified by prefix with TCP?

  11. Section 3.2:
   Notes on Established Session states:
      Session "Live" means transmitting or reeiving over a transfer
      stream.

      Session "Idle" means no transmission/reception over a transfer
      stream.

     Session "Closing" means no new transfers will be allowed.

Note that “Closing” is not used in Figure 4, it is called ending. Note spelling error on “live” receving.

  12. Section 3.2: Figure 5 and 6 uses PCH without explanation. Figure 5 could probably also benefit by expanding CH as Contact Header.

  13. Figure 8 and 10: Uses [SESSTERM] is this the same as using the SESS_TERM message, or some other procedure. Please clarify.

  14. Section 3.3: “   Many other policies can be established in a TCPCL network between these two extremes.”

The list above includes three items, so the two extremes needs to be enumerated.

  15. Section 4.1: Can TCPCLv3 and TCPCLv4 coexist on Port 4556? Based on 9.1 the answer is yes, please clarify here.

  16. Section 4.1: “Therefore, the entity MUST retry the connection setup no earlier than some delay time from the last attempt, and it SHOULD use a (binary) exponential backoff mechanism to increase this delay in case of repeated failures.”

Any recommended upper limit for the backoff?

  17. Section 4.2:    Version:  A one-octet field value containing the value 4 (current version of the protocol).

I think the use of “the protocol” is unclear, maybe call it “the TCP convergence layer”. This to avoid confusion with BPv7.

  18. Section 4.2: Please define how to set and ignore reserved bits in the Flags field so that it may be extended in the future.

  19. Section 4.3 and 4.4: Due to how the Contact Header relate to TLS there is clear risk for a TLS stripping attack where the CAN_TLS flag is cleared. I think there need to be some thought about mitigation of this weakness. Depending on the expected mix of entities and their capabilities one can either have policy for a deployment where one mandates TLS being used, thus preventing the bid-down by not being according to policy. It is more difficult to mitigate in a deployment where one have some entities that doesn’t support TLS, unless one can some way securely learn which entities support it or not and thus can detect the manipulation. One can potentially also first attempt to do a TLS handshake for the best version one supports. Then run the CH inside the TLS to prevent TCPCL version and other flags to be manipulated. But that doesn’t solve the down-bid. I did note the negotiation in Section 4.7 and the relation to Security Policy. Maybe the solution is to write some text on the risk of TLS striping in Section 8 and add forward pointers in 4.7 to that risk.

  20. Section 4.4: Dealing with new TLS versions. BCP 195 does not appear to me to define how to deal with newer versions. However, as TLS 1.3 already exist I think this is from the start a relevant question.

  21. Section 4.4: So what about entity authentication? Will the TCPCL entity have a name / identity that can be authenticated so that one know that one are talking to the right entity. And is the solution for this a classical PKI, or something else? Also does the passive entity expect the active (TLS client) to authenticate itself also?

  22. Section 4.8: Please define how to set and ignore the reserved bits.

  23. Section 4.5: Based on that many later sections just refer to the Message Header, shouldn’t the section title for section 4.5 be Message Header? Now the first mentioning of “Message Header” are in Figure 16’s title.

  24. Section 6.1:
   After sending a SESS_TERM message, an entity MAY continue a possible
   in-progress transfer in either direction.  After sending a SESS_TERM
   message, an entity SHALL NOT begin any new outgoing transfer (i.e.
   send an XFER_SEGMENT message) for the remainder of the session.
   After receving a SESS_TERM message, an entity SHALL NOT accept any
   new incoming transfer for the remainder of the session.

To me it seems that the above paragraph contains one contradiction. The parenthesis in the second sentence (i.e. send an XFER_SEGMENT message) appears to be false. Because as the beginning of the sentence implies that it can’t start a new transfer. However SESS_TERM is allowed to be inserted in between XFER_SEGEMENT messages for a transfer ID, i.e. XFER_SEGMENT(ID=7), SESS_TERM, XFER_SEGMENT(ID=7, end) is an allowed sequence. Can you please clarify.

  25. Section 8.
If this identifier is used outside of a TLS-secured session or
   without further verification as a means to determine which bundles
   are transmitted over the session, then the node that has falsified
   its identity would be able to obtain bundles that it otherwise would
   not have.

I don’t see how a entity could trust the in SESS_INIT provided EID more just because it is in TLS unless there are some mechanism for binding the EID to the TLS session endpoint (client or server). Some type of authentication is needed to prove the identity.

  26. Section 8.
Therefore, an entity SHALL NOT use the EID value of an
unsecured contact header to derive a peer node's identity unless it
   can corroborate it via other means.

The EID value is not part of the CH, only SESS_INIT. Is this a left over from TCPCLv3 or earlier versions?

  27. Section 8. Needs text on  TLS stripping attack due to the optional TLS usage.

  28. Section 9: “In this section, registration procedures are as defined in [RFC8126].” … defined as in …

  29. Section 9: “Some of the registries below are created new for TCPCLv4 but share code values with TCPCLv3.”

I don’t think “share” is the right word here. Maybe “Some of the registries have been defined as version specific to TCPCLv4, and imports some or all codepoints from TCPCLv3.”

  30. Section 9.3: Is RFC Required unnecessary strict? Considering the quite large name space, I would think that specification required would be a suitable policy? Just trying to understand what you think is gained by having someone publish the extension as an RFC, in any stream including the independent.

  31. Section 9.4: Same question as for 30)

  32. Section 9.5: Here RFC required may be suitable. However, does it make sense to allocate 2 or 4 points also here for Private/Experiments?

  33. Section 9.6: Here I would consider Expert Review with a specification requirement. I also do not understand why so much is reserved, a reason for that?

  34. I would expect that the policy for 9.6-9.8 to be aligned so may require change if change is decided on 33.

  35. A big question I have after having read this document is how one discover / determine the IP+port(s) to connect to for a given EID. Is this currently completely deployment specific? And how bound is this to Bundle routing?

What may be missing is the section that tells the intended implementor that in addition to follow this specification you do need a solution to the following things, like for example authentication framework that allows one to verify the TLS connects to EID mappings. Or an address resolution protocol that maps EID to IP address and port pairs for cases when routing simply give you Forward this bundle to EID using TCPCLv4.

Cheers

Magnus Westerlund

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 8 Aug 2019 22:39:10 +0000

Hi.  A couple of thoughts here:

1.  In section 4.1.5.2 of the bpbis I-D we explain how nodes are identified by node IDs and how node IDs are a subset of (though syntactically indistinguishable from) EIDs.

2.  There is no need for TCPCL to have any awareness of BP endpoint IDs at all.  BP endpoints are the destinations of bundles, used for routing in the network; TCPCL plays no part in bundle routing.

3.  What TCPCL needs to be aware of is the IDs of the BP nodes on whose behalf it is acting.  Node IDs, not endpoint IDs.

4.  When a remote TCPCL entity makes a TCP connection to the local TCPCL entity, contact headers are exchanged; the IDs of the BP nodes served by the two TCPCL entities are noted in the contact headers.  At the local TCPCL entity, this enables bundles that are queued up for transmission to the BP node served by the remote TCPCL entity to be dequeued and transmitted correctly via the new TCP connection.

5.  It is of course possible for the remote TCPCL entity's contact header to be incorrect or malicious, falsely claiming association with the cited BP node.  To this end, maybe one of the data items in the contact header should be a signature over the whole contact header, signed in the private key of the remote TCPCL entity's associated BP node.  When each TCPCL entity receives the other's contact header and reads the node ID, it could use the cited node's public key to validate the contact header's signature.

Scott

From: dtn <[email-masked]> On Behalf Of Brian Sipos
Sent: Thursday, August 8, 2019 2:18 PM
To: [email-masked]
Subject: [EXTERNAL] Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

All,

Thanks for any guidance,
Brian S.

________________________________________
From: Magnus Westerlund
Sent: Thursday, August 01, 2019 09:31
To: mailto:[email-masked]; mailto:[email-masked]
Subject: AD review of draft-ietf-dtn-tcpclv4-12 

Hi,

1. Section 1: What are the applicability of TCPCLv4 to BPv6? I wonder as RFC5050 is referenced. 
2. Section 1.1: Session State Changed. Some editorial issues. Missing ":" initially. Then double ".." on Terminated. 
3. Section 1.1: 
   Session Idle Changed  The TCPCL supports indication when the live/idle sub-state changes.  This occurs only when the top-level session state is Established.  Because TCPCL transmits serially over a TCP connection, it suffers from "head of queue blocking" this indication provides information about when a session is available for immediate transfer start.

So in which direction are this change indicated/reported, both or only in one of them, or any as implied by Section 2.1's definition of Live Session? 
4. Section 1.1: Transmission Intermediate Progress: Segment is not defined prior to this. Maybe a forward pointe? Or should maybe the whole subsection (1.1) be moved to after definitions? 
5. Section 2: Is there a point to use the RFC 8174 language that makes only capital words have special meaning? 
6. Section 3.1: "One of these parameters is a singleton endpoint identifier for each node (not the singleton Endpoint Identifier (EID) of any application running on the node) to denote the bundle-layer identity of each DTN node."

The above quote does imply something that at least BPBis isn't making clear that a particular application agent would have its own EID. It is not clear that there are a one-to-one relationship between bundle nodes and application agents. Can you please clarify what the relationship is and lets figure out if that needs to be clarified back to BPbis. 
7. Section 3.1: "Bundle interleaving can be accomplished by fragmentation at the BP layer or by establishing multiple TCPCL sessions between the same peers."

10. Figure 4: "Close message" is this TCP level message, if that is the case can that be clarified by prefix with TCP?

Note that "Closing" is not used in Figure 4, it is called ending. Note spelling error on "live" receving.
12. Section 3.2: Figure 5 and 6 uses PCH without explanation. Figure 5 could probably also benefit by expanding CH as Contact Header.
13. Figure 8 and 10: Uses [SESSTERM] is this the same as using the SESS_TERM message, or some other procedure. Please clarify. 
14. Section 3.3: "   Many other policies can be established in a TCPCL network between these two extremes."

The list above includes three items, so the two extremes needs to be enumerated. 
15. Section 4.1: Can TCPCLv3 and TCPCLv4 coexist on Port 4556? Based on 9.1 the answer is yes, please clarify here.
16. Section 4.1: "Therefore, the entity MUST retry the connection setup no earlier than some delay time from the last attempt, and it SHOULD use a (binary) exponential backoff mechanism to increase this delay in case of repeated failures."

I think the use of "the protocol" is unclear, maybe call it "the TCP convergence layer". This to avoid confusion with BPv7. 
18. Section 4.2: Please define how to set and ignore reserved bits in the Flags field so that it may be extended in the future. 
19. Section 4.3 and 4.4: Due to how the Contact Header relate to TLS there is clear risk for a TLS stripping attack where the CAN_TLS flag is cleared. I think there need to be some thought about mitigation of this weakness. Depending on the expected mix of entities and their capabilities one can either have policy for a deployment where one mandates TLS being used, thus preventing the bid-down by not being according to policy. It is more difficult to mitigate in a deployment where one have some entities that doesn't support TLS, unless one can some way securely learn which entities support it or not and thus can detect the manipulation. One can potentially also first attempt to do a TLS handshake for the best version one supports. Then run the CH inside the TLS to prevent TCPCL version and other flags to be manipulated. But that doesn't solve the down-bid. I did note the negotiation in Section 4.7 and the relation to Security Policy. Maybe the solution is to write some text on the risk of TLS striping in Section 8 and add forward pointers in 4.7 to that risk. 
20. Section 4.4: Dealing with new TLS versions. BCP 195 does not appear to me to define how to deal with newer versions. However, as TLS 1.3 already exist I think this is from the start a relevant question. 
21. Section 4.4: So what about entity authentication? Will the TCPCL entity have a name / identity that can be authenticated so that one know that one are talking to the right entity. And is the solution for this a classical PKI, or something else? Also does the passive entity expect the active (TLS client) to authenticate itself also? 
22. Section 4.8: Please define how to set and ignore the reserved bits.
23. Section 4.5: Based on that many later sections just refer to the Message Header, shouldn't the section title for section 4.5 be Message Header? Now the first mentioning of "Message Header" are in Figure 16's title. 
24. Section 6.1:
   After sending a SESS_TERM message, an entity MAY continue a possible
   in-progress transfer in either direction.  After sending a SESS_TERM
   message, an entity SHALL NOT begin any new outgoing transfer (i.e.
   send an XFER_SEGMENT message) for the remainder of the session..
   After receving a SESS_TERM message, an entity SHALL NOT accept any
   new incoming transfer for the remainder of the session. 

To me it seems that the above paragraph contains one contradiction. The parenthesis in the second sentence (i.e. send an XFER_SEGMENT message) appears to be false. Because as the beginning of the sentence implies that it can't start a new transfer. However SESS_TERM is allowed to be inserted in between XFER_SEGEMENT messages for a transfer ID, i.e. XFER_SEGMENT(ID=7), SESS_TERM, XFER_SEGMENT(ID=7, end) is an allowed sequence. Can you please clarify.
25. Section 8. 

I don't see how a entity could trust the in SESS_INIT provided EID more just because it is in TLS unless there are some mechanism for binding the EID to the TLS session endpoint (client or server). Some type of authentication is needed to prove the identity. 
26. Section 8.
Therefore, an entity SHALL NOT use the EID value of an
unsecured contact header to derive a peer node's identity unless it
   can corroborate it via other means.

The EID value is not part of the CH, only SESS_INIT. Is this a left over from TCPCLv3 or earlier versions?
27. Section 8. Needs text on  TLS stripping attack due to the optional TLS usage.
28. Section 9: "In this section, registration procedures are as defined in [RFC8126]." . defined as in .
29. Section 9: "Some of the registries below are created new for TCPCLv4 but share code values with TCPCLv3."

I don't think "share" is the right word here. Maybe "Some of the registries have been defined as version specific to TCPCLv4, and imports some or all codepoints from TCPCLv3."

Cheers
 
Magnus Westerlund

---

From: Brian Sipos <[email-masked]>
Date: Fri, 9 Aug 2019 15:08:59 +0000

Scott,
For #1-3, should the CL spec use the term "Node ID" instead? The Endpoint ID term was carried over from TCPCLv3 quite blindly, as I am less familiar with bundle routing logic than transport logic.

Regarding #4-5, is it true that a CL contact/session is likely to be established with a peer already known to the BP agent and already associated with a Node ID? Or is it just as likely to do something like proactively attempt TCPCL sessions with all addresses in a local subnet to coarsely 'discover' other nodes?

My feeling on the TLS authentication topic is to allow any of the following:

  *   Authenticate the IP peer name/address using X.509 subjectAltName of type dNSName or iPAddress
  *   Authenticate the DTN peer Node ID using subjectAltName of type uniformResourceIdentifier

Then it would be up to each entity policy of when to require authentication, and the auth'n could occur on either/both ends of the CL session regardless of which entity is the passive or active role.
________________________________
From: dtn <[email-masked]> on behalf of Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>
Sent: Thursday, August 8, 2019 18:39
To: [email-masked] <[email-masked]>
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

Scott

All,

Thanks for any guidance,
Brian S.

Hi,

Cheers

Magnus Westerlund

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 9 Aug 2019 23:11:54 +0000

Hi, Brian.  First, yes, I do think the terminology is worth getting right, and I think we've been less than precise in the past.  A "node" is an entity that can send or receive bundles, comprising a bundle protocol agent, a set of zero or more convergence layer adapters, and an application agent; an "endpoint" is a set of zero or more nodes that all identify themselves for BP purposes by a common identified, i.e., an endpoint ID.  The source of a bundle is a node; the destination of a bundle is an endpoint (often a "singleton endpoint" that always contains exactly one member).

The way I understand TCPCL (at least in terms of socket-based implementations) is that any node can use its TCPCL adapter in one of two ways to enable communication via the TCPCL adapter of any other node:

1.       If it knows the IP address and port number of the socket on which that remote node's TCPCL adapter is accepting connections, then the local TCPCL adapter can create a socket of its own and connect that socket to the remote socket.

2.       The local TCPCL adapter's connection acceptance socket can accept a connection from the socket of a remote node's TCPCL adapter.

In case 1, it necessarily has information associating the node with the socket address; in case 2 it doesn't, which is why the ID of the associated node has to be provided in the contact header.

Node discovery is an altogether different mechanism; a node might use the ipnd node discovery protocol to acquire the information needed for case 1 (for multiple nodes in the local subnet, for example), but alternatively that information might be provided by some sort of management function.

The key point is that the association between node and socket address is information that has to come from somewhere (management, node discovery, the contact header) in order for bundles to flow, and that information might be accidentally or maliciously incorrect no matter where it comes from.

I figure one easy and straightforward way to authenticate the node ID is to check a signature (covering part or all of the contact header, and included in the contact header) computed in the private key of the purported node; the authenticating node is likely to need that node's public key anyway in order to run bpsec.

If there are easier ways, I'm for 'em.  But I would caution us against relying too heavily on capabilities that are readily available on the Internet, since not all DTN nodes that use TCPCL are going to be on the Internet.  (For example, the LANs on the International Space Station.)

Scott

From: Brian Sipos <[email-masked]>
Sent: Friday, August 9, 2019 8:09 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: AD review of draft-ietf-dtn-tcpclv4-12

Scott,

  *   Authenticate the IP peer name/address using X.509 subjectAltName of type dNSName or iPAddress
  *   Authenticate the DTN peer Node ID using subjectAltName of type uniformResourceIdentifier
Then it would be up to each entity policy of when to require authentication, and the auth'n could occur on either/both ends of the CL session regardless of which entity is the passive or active role.
________________________________
From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]<mailto:scott.c.burleigh=[email-masked]>>
Sent: Thursday, August 8, 2019 18:39
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

Scott

From: dtn <[email-masked]<mailto:[email-masked]>> On Behalf Of Brian Sipos
Sent: Thursday, August 8, 2019 2:18 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

All,

Thanks for any guidance,
Brian S.

Hi,

   send an XFER_SEGMENT message) for the remainder of the session...

Cheers

Magnus Westerlund

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

---

From: Brian Sipos <[email-masked]>
Date: Tue, 13 Aug 2019 12:58:42 +0000

Scott,
Okay, I will scrub the "endpoint" language from the CL spec because all the CL should deal with is inter-node transport. My feeling on the authentication side (binding the Node ID to the TLS session) is to just use the pre-existing X.509 mechanism for identifying the subject of a certificate as a URI since Node IDs are already a URI. This involves no protocol change and is consistent with other TLS-using protocols.

One other carry-over from TCPCLv3 is the association of a single Node ID with a CL session. Is it correct that there is no sensible reason for a single TCPCL session to have any more than a single Node ID? This is not to say that a single BP Agent can't have different TCPCL sessions each expressing a different Node ID, but within each session each TCPCL entity has exactly one Node ID.
________________________________
From: Burleigh, Scott C (US 312B) <[email-masked]>
Sent: Friday, August 9, 2019 19:11
To: Brian Sipos <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: AD review of draft-ietf-dtn-tcpclv4-12

Hi, Brian.  First, yes, I do think the terminology is worth getting right, and I think we’ve been less than precise in the past.  A “node” is an entity that can send or receive bundles, comprising a bundle protocol agent, a set of zero or more convergence layer adapters, and an application agent; an “endpoint” is a set of zero or more nodes that all identify themselves for BP purposes by a common identified, i.e., an endpoint ID.  The source of a bundle is a node; the destination of a bundle is an endpoint (often a “singleton endpoint” that always contains exactly one member).

1.       If it knows the IP address and port number of the socket on which that remote node’s TCPCL adapter is accepting connections, then the local TCPCL adapter can create a socket of its own and connect that socket to the remote socket.

2.       The local TCPCL adapter’s connection acceptance socket can accept a connection from the socket of a remote node’s TCPCL adapter.

In case 1, it necessarily has information associating the node with the socket address; in case 2 it doesn’t, which is why the ID of the associated node has to be provided in the contact header.

I figure one easy and straightforward way to authenticate the node ID is to check a signature (covering part or all of the contact header, and included in the contact header) computed in the private key of the purported node; the authenticating node is likely to need that node’s public key anyway in order to run bpsec.

If there are easier ways, I’m for ‘em.  But I would caution us against relying too heavily on capabilities that are readily available on the Internet, since not all DTN nodes that use TCPCL are going to be on the Internet.  (For example, the LANs on the International Space Station.)

Scott

Scott,

Scott

All,

Thanks for any guidance,
Brian S.

Hi,

Cheers

Magnus Westerlund

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Tue, 13 Aug 2019 13:40:25 +0000

Hi, Brian.  I can't think of any reason for any single TCPCL session to have more than one node (identified by a single node ID) at each end of the connection.  I think that was the intent of the original TCPCL design, but if anybody knows better please speak up.

Would X.509 authentication require access to some infrastructure (servers, CAs, whatever) that is provided by the Internet?  If we were running TCPCL on ISS, which is not connected to the Internet, would X.509 authentication still be supported?  Or would it require instantiation of new infrastructure on ISS?

Scott

From: Brian Sipos <[email-masked]>
Sent: Tuesday, August 13, 2019 5:59 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: AD review of draft-ietf-dtn-tcpclv4-12

Scott,

One other carry-over from TCPCLv3 is the association of a single Node ID with a CL session. Is it correct that there is no sensible reason for a single TCPCL session to have any more than a single Node ID? This is not to say that a single BP Agent can't have different TCPCL sessions each expressing a different Node ID, but within each session each TCPCL entity has exactly one Node ID.
________________________________
From: Burleigh, Scott C (US 312B) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 9, 2019 19:11
To: Brian Sipos <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: AD review of draft-ietf-dtn-tcpclv4-12

Scott

From: Brian Sipos <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 9, 2019 8:09 AM
To: Burleigh, Scott C (US 312B) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: AD review of draft-ietf-dtn-tcpclv4-12

Scott,

Scott

All,

Thanks for any guidance,
Brian S.

Hi,

Cheers

Magnus Westerlund

---

From: Brian Sipos <[email-masked]>
Date: Tue, 13 Aug 2019 21:19:49 +0000

Scott,
All of the X509 activities can be done in an isolated network. The name binding of a certificate is self-contained and depends only on the agent trusting of the certificate. Trust can be obtained by tracing back to a trusted CA (which is a disconnected activity) or by trusting the certificate directly (called "pinning").

In a simple example, there is one private-network CA which directly signs all of the node certificates. Each node is issued its certificate which binds it to a single Node ID (URI). When using TCPCL both nodes of the CL session:

  1.  Each node presents their certificate during TLS handshake
  2.  Each node presents their Node ID during SESS_INIT exchange
  3.  The receiving node then:
     *   Authenticates the peer certificate with the shared CA
     *   Authenticates the Node ID based on the certificate contents

There are plenty of more complicated situations, because a certificate can contain any number of URIs the same cert can be used by many different nodes (all sharing the same private key) and these kinds of decisions of sharing key purposes are left to security policy.
________________________________
From: Burleigh, Scott C (US 312B) <[email-masked]>
Sent: Tuesday, August 13, 2019 09:40
To: Brian Sipos <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: AD review of draft-ietf-dtn-tcpclv4-12

Hi, Brian.  I can’t think of any reason for any single TCPCL session to have more than one node (identified by a single node ID) at each end of the connection.  I think that was the intent of the original TCPCL design, but if anybody knows better please speak up.

Scott

Scott,

Scott

Scott,

Scott

All,

Thanks for any guidance,
Brian S.

Hi,

Cheers

Magnus Westerlund

---

From: "Marc Blanchet" <[email-masked]>
Date: Tue, 13 Aug 2019 17:25:59 -0400

On 13 Aug 2019, at 17:19, Brian Sipos wrote:

> Scott,
> All of the X509 activities can be done in an isolated network. The 
> name binding of a certificate is self-contained and depends only on 
> the agent trusting of the certificate. Trust can be obtained by 
> tracing back to a trusted CA (which is a disconnected activity) or by 
> trusting the certificate directly (called "pinning").

or even more simply: verifying nodes may have a local copy of the certs 
they trust. Does not scale well, but…

Marc.

>
> In a simple example, there is one private-network CA which directly 
> signs all of the node certificates. Each node is issued its 
> certificate which binds it to a single Node ID (URI). When using TCPCL 
> both nodes of the CL session:
>
> There are plenty of more complicated situations, because a certificate 
> can contain any number of URIs the same cert can be used by many 
> different nodes (all sharing the same private key) and these kinds of 
> decisions of sharing key purposes are left to security policy.
> Hi, Brian.  I can’t think of any reason for any single TCPCL session 
> to have more than one node (identified by a single node ID) at each 
> end of the connection.  I think that was the intent of the original 
> TCPCL design, but if anybody knows better please speak up.
>
>
>
> Would X.509 authentication require access to some infrastructure 
> (servers, CAs, whatever) that is provided by the Internet?  If we were 
> running TCPCL on ISS, which is not connected to the Internet, would 
> X.509 authentication still be supported?  Or would it require 
> instantiation of new infrastructure on ISS?
>
>
>
> Scott
>
>
>
> Okay, I will scrub the "endpoint" language from the CL spec because 
> all the CL should deal with is inter-node transport. My feeling on the 
> authentication side (binding the Node ID to the TLS session) is to 
> just use the pre-existing X.509 mechanism for identifying the subject 
> of a certificate as a URI since Node IDs are already a URI. This 
> involves no protocol change and is consistent with other TLS-using 
> protocols.
>
>
>
> One other carry-over from TCPCLv3 is the association of a single Node 
> ID with a CL session. Is it correct that there is no sensible reason 
> for a single TCPCL session to have any more than a single Node ID? 
> This is not to say that a single BP Agent can't have different TCPCL 
> sessions each expressing a different Node ID, but within each session 
> each TCPCL entity has exactly one Node ID.
>
> From: Burleigh, Scott C (US 312B) 
> <[email-masked]<mailto:[email-masked]>>
> To: Brian Sipos <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
> Hi, Brian.  First, yes, I do think the terminology is worth getting 
> right, and I think we’ve been less than precise in the past.  A 
> “node” is an entity that can send or receive bundles, comprising a 
> bundle protocol agent, a set of zero or more convergence layer 
> adapters, and an application agent; an “endpoint” is a set of zero 
> or more nodes that all identify themselves for BP purposes by a common 
> identified, i.e., an endpoint ID.  The source of a bundle is a node; 
> the destination of a bundle is an endpoint (often a “singleton 
> endpoint” that always contains exactly one member).
>
>
>
> The way I understand TCPCL (at least in terms of socket-based 
> implementations) is that any node can use its TCPCL adapter in one of 
> two ways to enable communication via the TCPCL adapter of any other 
> node:
>
> 1.       If it knows the IP address and port number of the socket on 
> which that remote node’s TCPCL adapter is accepting connections, 
> then the local TCPCL adapter can create a socket of its own and 
> connect that socket to the remote socket.
>
> 2.       The local TCPCL adapter’s connection acceptance socket can 
> accept a connection from the socket of a remote node’s TCPCL 
> adapter.
>
>
>
> In case 1, it necessarily has information associating the node with 
> the socket address; in case 2 it doesn’t, which is why the ID of the 
> associated node has to be provided in the contact header.
>
>
>
> Node discovery is an altogether different mechanism; a node might use 
> the ipnd node discovery protocol to acquire the information needed for 
> case 1 (for multiple nodes in the local subnet, for example), but 
> alternatively that information might be provided by some sort of 
> management function.
>
>
>
> The key point is that the association between node and socket address 
> is information that has to come from somewhere (management, node 
> discovery, the contact header) in order for bundles to flow, and that 
> information might be accidentally or maliciously incorrect no matter 
> where it comes from.
>
>
>
> I figure one easy and straightforward way to authenticate the node ID 
> is to check a signature (covering part or all of the contact header, 
> and included in the contact header) computed in the private key of the 
> purported node; the authenticating node is likely to need that 
> node’s public key anyway in order to run bpsec.
>
>
>
> If there are easier ways, I’m for ‘em.  But I would caution us 
> against relying too heavily on capabilities that are readily available 
> on the Internet, since not all DTN nodes that use TCPCL are going to 
> be on the Internet..  (For example, the LANs on the International 
> Space Station.)
>
>
>
> Scott
>
>
>
> To: Burleigh, Scott C (US 312B) 
> <[email-masked]<mailto:[email-masked]>>; 
> For #1-3, should the CL spec use the term "Node ID" instead? The 
> Endpoint ID term was carried over from TCPCLv3 quite blindly, as I am 
> less familiar with bundle routing logic than transport logic.
>
>
>
> Regarding #4-5, is it true that a CL contact/session is likely to be 
> established with a peer already known to the BP agent and already 
> associated with a Node ID? Or is it just as likely to do something 
> like proactively attempt TCPCL sessions with all addresses in a local 
> subnet to coarsely 'discover' other nodes?
>
>
>
> Then it would be up to each entity policy of when to require 
> authentication, and the auth'n could occur on either/both ends of the 
> CL session regardless of which entity is the passive or active role.
>
> From: dtn <[email-masked]<mailto:[email-masked]>> on 
> behalf of Burleigh, Scott C (US 312B) 
> <scott.c.burleigh=[email-masked]<mailto:scott.c.burleigh=[email-masked]>>
> <[email-masked]<mailto:[email-masked]>>
> 1.  In section 4.1.5.2 of the bpbis I-D we explain how nodes are 
> identified by node IDs and how node IDs are a subset of (though 
> syntactically indistinguishable from) EIDs.
>
> 2.  There is no need for TCPCL to have any awareness of BP endpoint 
> IDs at all.  BP endpoints are the destinations of bundles, used for 
> routing in the network; TCPCL plays no part in bundle routing.
>
> 3.  What TCPCL needs to be aware of is the IDs of the BP nodes on 
> whose behalf it is acting.  Node IDs, not endpoint IDs.
>
> 4.  When a remote TCPCL entity makes a TCP connection to the local 
> TCPCL entity, contact headers are exchanged; the IDs of the BP nodes 
> served by the two TCPCL entities are noted in the contact headers.  At 
> the local TCPCL entity, this enables bundles that are queued up for 
> transmission to the BP node served by the remote TCPCL entity to be 
> dequeued and transmitted correctly via the new TCP connection.
>
> 5.  It is of course possible for the remote TCPCL entity's contact 
> header to be incorrect or malicious, falsely claiming association with 
> the cited BP node.  To this end, maybe one of the data items in the 
> contact header should be a signature over the whole contact header, 
> signed in the private key of the remote TCPCL entity's associated BP 
> node.  When each TCPCL entity receives the other's contact header and 
> reads the node ID, it could use the cited node's public key to 
> validate the contact header's signature.
>
> Scott
>
> Because I am less familiar with the nuances of preexisting DTN and 
> TCPCLv3 uses, can anyone help inform me about how the EID was/is 
> intended to be used as part of the TCPCL. As Magnus points out, as 
> currently written (and as a carry-over from TCPCLv3) there is no 
> mechanism to authenticate that the EID sent by a TCPCL Entity is 
> properly bound to the host sending it. Is there a purpose for this EID 
> other than manual troubleshooting?
>
> I'm planning on adding some text explaining how TLS with X.509can be 
> used to authenticate the TCPCL peer based on the hostname/address used 
> for the TCP connection in accordance with RFC 6125. It would also be 
> possible to authenticate the EID as a subject URI of a peer 
> certificate. Does this seem reasonable and desirable?
>
> Thanks for any guidance,
> Brian S.
>
> I have now performed my AD review of draft-ietf-dtn-tcpclv4-12. I 
> think most are minor comments, however the TLS and security related 
> ones may be more problematic to resolve. I will now be on vacation so 
> you know you will not receive any quick replies from me before the end 
> of the month.
>
> 2. Section 1.1: Session State Changed. Some editorial issues. Missing 
> ":" initially. Then double ".." on Terminated.
> 3. Section 1.1:
>    Session Idle Changed  The TCPCL supports indication when the 
> live/idle sub-state changes.  This occurs only when the top-level 
> session state is Established.  Because TCPCL transmits serially over a 
> TCP connection, it suffers from "head of queue blocking" this 
> indication provides information about when a session is available for 
> immediate transfer start.
>
> So in which direction are this change indicated/reported, both or only 
> in one of them, or any as implied by Section 2.1's definition of Live 
> Session?
> 4. Section 1.1: Transmission Intermediate Progress: Segment is not 
> defined prior to this. Maybe a forward pointe? Or should maybe the 
> whole subsection (1.1) be moved to after definitions?
> 6. Section 3.1: "One of these parameters is a singleton endpoint 
> identifier for each node (not the singleton Endpoint Identifier (EID) 
> of any application running on the node) to denote the bundle-layer 
> identity of each DTN node."
>
> The above quote does imply something that at least BPBis isn't making 
> clear that a particular application agent would have its own EID. It 
> is not clear that there are a one-to-one relationship between bundle 
> nodes and application agents. Can you please clarify what the 
> relationship is and lets figure out if that needs to be clarified back 
> to BPbis.
> 7. Section 3.1: "Bundle interleaving can be accomplished by 
> fragmentation at the BP layer or by establishing multiple TCPCL 
> sessions between the same peers."
>
> Are there clear rules established for how many TCPCL sessions in 
> parallel that may be established? By the end of my reading this is 
> unanswered.
> 8. Section 3.1: XFER_REFUSE does that indicate that the bundle has 
> already been received. How else does one separate other reasons for 
> refusing a bundle versus that one have received it prior?
> 10. Figure 4: "Close message" is this TCP level message, if that is 
> the case can that be clarified by prefix with TCP?
> 11. Section 3.2:
> 12. Section 3.2: Figure 5 and 6 uses PCH without explanation. Figure 5 
> could probably also benefit by expanding CH as Contact Header.
> 13. Figure 8 and 10: Uses [SESSTERM] is this the same as using the 
> SESS_TERM message, or some other procedure. Please clarify.
> 15. Section 4.1: Can TCPCLv3 and TCPCLv4 coexist on Port 4556? Based 
> on 9.1 the answer is yes, please clarify here.
> 16. Section 4.1: "Therefore, the entity MUST retry the connection 
> setup no earlier than some delay time from the last attempt, and it 
> SHOULD use a (binary) exponential backoff mechanism to increase this 
> delay in case of repeated failures."
>
> 17. Section 4.2:    Version:  A one-octet field value containing the 
> value 4 (current version of the protocol).
>
> I think the use of "the protocol" is unclear, maybe call it "the TCP 
> convergence layer". This to avoid confusion with BPv7.
> 18. Section 4.2: Please define how to set and ignore reserved bits in 
> the Flags field so that it may be extended in the future.
> 19. Section 4.3 and 4.4: Due to how the Contact Header relate to TLS 
> there is clear risk for a TLS stripping attack where the CAN_TLS flag 
> is cleared. I think there need to be some thought about mitigation of 
> this weakness. Depending on the expected mix of entities and their 
> capabilities one can either have policy for a deployment where one 
> mandates TLS being used, thus preventing the bid-down by not being 
> according to policy. It is more difficult to mitigate in a deployment 
> where one have some entities that doesn't support TLS, unless one can 
> some way securely learn which entities support it or not and thus can 
> detect the manipulation. One can potentially also first attempt to do 
> a TLS handshake for the best version one supports. Then run the CH 
> inside the TLS to prevent TCPCL version and other flags to be 
> manipulated. But that doesn't solve the down-bid. I did note the 
> negotiation in Section 4.7 and the relation to Security Policy. Maybe 
> the solution is to write some text on the risk of TLS striping in 
> Section 8 and add forward pointers in 4.7 to that risk.
> 20. Section 4.4: Dealing with new TLS versions. BCP 195 does not 
> appear to me to define how to deal with newer versions. However, as 
> TLS 1.3 already exist I think this is from the start a relevant 
> question.
> 21. Section 4.4: So what about entity authentication? Will the TCPCL 
> entity have a name / identity that can be authenticated so that one 
> know that one are talking to the right entity. And is the solution for 
> this a classical PKI, or something else? Also does the passive entity 
> expect the active (TLS client) to authenticate itself also?
> 23. Section 4.5: Based on that many later sections just refer to the 
> Message Header, shouldn't the section title for section 4.5 be Message 
> Header? Now the first mentioning of "Message Header" are in Figure 
> 16's title.
> 24. Section 6.1:
> To me it seems that the above paragraph contains one contradiction. 
> The parenthesis in the second sentence (i.e. send an XFER_SEGMENT 
> message) appears to be false. Because as the beginning of the sentence 
> implies that it can't start a new transfer. However SESS_TERM is 
> allowed to be inserted in between XFER_SEGEMENT messages for a 
> transfer ID, i.e. XFER_SEGMENT(ID=7), SESS_TERM, XFER_SEGMENT(ID=7, 
> end) is an allowed sequence. Can you please clarify.
> 25. Section 8.
> I don't see how a entity could trust the in SESS_INIT provided EID 
> more just because it is in TLS unless there are some mechanism for 
> binding the EID to the TLS session endpoint (client or server). Some 
> type of authentication is needed to prove the identity.
> 26. Section 8.
> 29. Section 9: "Some of the registries below are created new for 
> TCPCLv4 but share code values with TCPCLv3."
>
> I don't think "share" is the right word here. Maybe "Some of the 
> registries have been defined as version specific to TCPCLv4, and 
> imports some or all codepoints from TCPCLv3."
> 30. Section 9.3: Is RFC Required unnecessary strict? Considering the 
> quite large name space, I would think that specification required 
> would be a suitable policy? Just trying to understand what you think 
> is gained by having someone publish the extension as an RFC, in any 
> stream including the independent.
> 32. Section 9.5: Here RFC required may be suitable. However, does it 
> make sense to allocate 2 or 4 points also here for 
> Private/Experiments?
> 33. Section 9.6: Here I would consider Expert Review with a 
> specification requirement. I also do not understand why so much is 
> reserved, a reason for that?
> 34. I would expect that the policy for 9.6-9.8 to be aligned so may 
> require change if change is decided on 33.
> 35. A big question I have after having read this document is how one 
> discover / determine the IP+port(s) to connect to for a given EID. Is 
> this currently completely deployment specific? And how bound is this 
> to Bundle routing?
>
> What may be missing is the section that tells the intended implementor 
> that in addition to follow this specification you do need a solution 
> to the following things, like for example authentication framework 
> that allows one to verify the TLS connects to EID mappings. Or an 
> address resolution protocol that maps EID to IP address and port pairs 
> for cases when routing simply give you Forward this bundle to EID 
> using TCPCLv4.
>
> Cheers
>
> Magnus Westerlund
>

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Tue, 13 Aug 2019 23:30:10 +0000

Well, I was talking to some ISS guys at dinner and they assure me there is no issue: ISS does indeed connect to the Internet, or at least to ground-based infrastructure, so X.509 authentication of TCPCL/TLS sessions is fine with them.  So okay, no objection to X.509 from me.

Scott

-----Original Message-----
From: Marc Blanchet <[email-masked]> 
Sent: Tuesday, August 13, 2019 2:26 PM
To: Brian Sipos <[email-masked]>
Cc: Burleigh, Scott C (US 312B) <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

> trusting the certificate directly (called "pinning").

or even more simply: verifying nodes may have a local copy of the certs they trust. Does not scale well, but…

Marc.