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

["Marc Blanchet" <[e-mail]>]

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:
>
>   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) <[e-mail]>
> Sent: Tuesday, August 13, 2019 09:40
> To: Brian Sipos <[e-mail]>; [e-mail] <[e-mail]>
> 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.
>
>
>
> 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 <[e-mail]>
> Sent: Tuesday, August 13, 2019 5:59 AM
> To: Burleigh, Scott C (US 312B) <[e-mail]>; 
> [e-mail]
> Subject: [EXTERNAL] Re: AD review of draft-ietf-dtn-tcpclv4-12
>
>
>
> 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) 
> <[e-mail]<mailto:[e-mail]>>
> Sent: Friday, August 9, 2019 19:11
> To: Brian Sipos <[e-mail]<mailto:[e-mail]>>; 
> [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
> 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).
>
>
>
> 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 <[e-mail]<mailto:[e-mail]>>
> Sent: Friday, August 9, 2019 8:09 AM
> To: Burleigh, Scott C (US 312B) 
> <[e-mail]<mailto:[e-mail]>>; 
> [e-mail]<mailto:[e-mail]>
> Subject: [EXTERNAL] Re: AD review of draft-ietf-dtn-tcpclv4-12
>
>
>
> 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 <[e-mail]<mailto:[e-mail]>> on 
> behalf of Burleigh, Scott C (US 312B) 
> <scott.c.burleigh=[e-mail]<mailto:scott.c.burleigh=[e-mail]>>
> Sent: Thursday, August 8, 2019 18:39
> To: [e-mail]<mailto:[e-mail]> 
> <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
>
>
>
> 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 <[e-mail]<mailto:[e-mail]>> On 
> Behalf Of Brian Sipos
> Sent: Thursday, August 8, 2019 2:18 PM
> To: [e-mail]<mailto:[e-mail]>
> Subject: [EXTERNAL] Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
>
> 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: mailto:[e-mail]; mailto:[e-mail]
> 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
>
> _______________________________________________
> dtn mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dtn


> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn