Subject: [tcpm] Roman Danyliw's Discuss on draft-ietf-tcpm-converters-17: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 04 Mar 2020 20:55:12 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-tcpm-converters-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Deployed without constraints, there would be a number of concerning attacks
given this protocol’s design.  Christian Huitema’s SecDir review (thank you!)
notes some of them.  Helpfully, this draft presents various restrictive scoping
to mitigate these attacks under certain circumstances:

(a) Section 4.1. Transport Converters can be operated by network operators or
third parties.   Nevertheless, this document focuses on the single
administrative deployment case where the entity offering the connectivity
service to a client is also the entity which owns and operates the Transport
Converter.

(b) Section 9.1. Furthermore, ingress filtering policies MUST be enforced at
the network boundaries [RFC2827].

(c) Section 9.2. The Convert Protocol is intended to be used in managed
networks where end hosts can be identified by their IP address.

(d) Section 9.2.  Stronger mutual authentication schemes MUST be defined to use
the Convert Protocol in more open network environments.

Unfortunately, the protocol mechanism to operate outside of these bounds is in
scope because (a) and (c) include no normative language.  For example, this
document doesn’t address converters operated by third parties but it explicitly
allows for their possibility with no discussion of the impact.

As this is an experimental document where implementation experience likely is
needed for refinement, could a compromise be found with an applicability
statement that shrinks the threat model and provide better normative guidance. 
For example (paraphrasing):

Applicability statement: Transport Converters MUST only be deployed in a single
administrative domain deployment model.  The entity offering the connectivity
service to a client MUST also be entity which owns and operates the Transport
Converter, with no transit over a third-party network.

For the Security Considerations: The Convert Protocol is RECOMMENDED to be used
in a managed network where end hosts can be identified by their IP address.  If
such control is not exerted and there is a more open network environment, a
strong mutual authentication scheme MUST be defined to use the Convert Protocol.

** Section 9.1.  Per “Given its function and its location in the network, a
Transport Converter has access to the payload of all the packets that it
processes.”, it’s a per more than that.  It is in a position to observe all
packets, so that’s payload, meta-data and the ability to profile and conduct
traffic analysis.  Perhaps something on the order of “Given its function and
location in the network, a Transport Convert is in a position to observe all
packets, to include payloads and meta-data; and has the ability to profile and
conduct traffic analysis of user behavior”.

** Section 9.1.  Per “As such, it MUST be protected as a core IP router (e.g.,
[RFC1812])”, no disagreement on the need to protect this router.  However, what
exact practices are being suggested?  Given the RFC1812, reference, what
specific sections apply?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 1.2. Given that Section 4.1. outlines that the architecture consists
of clients, converter and servers, the language in the list following “In
particular, a Transport Converter achieves the following :” might benefit from
consistency (i.e., final target server vs. server; and server vs. converter)

** Section 6.2.5.  Per “Upon reception of an Extended Connect TLV, a Transport
Converter first checks whether it supports the TCP Options listed in the 'TCP
Options' field.  If not, it returns an error message (Section 6.2.8).”, what
error does it return?

** Section 9.1  Per “The Transport Converter is designed to not leak such
sensitive information outside a local domain.”, can you clarify what that means.

** Editorially, the guidance in Section 9.2 and 9.5 needs to link   Section 9.2
provide an authentication/authorization solution given a certain topology, and
does Section 9.5.

** Editorial Nit
-- Section 2. Typo. s/a important/an important/
-- Section 4.4.1. Typo. s/the the/the/

---

From: <[email-masked]>
Date: Thu, 5 Mar 2020 07:33:10 +0000

Hi Roman, 

Thank you for the review.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Roman Danyliw via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 5 mars 2020 05:55
> À : The IESG
> Cc : [email-masked]; [email-masked];
> [email-masked]; Michael Scharf; [email-masked]
> Objet : Roman Danyliw's Discuss on draft-ietf-tcpm-converters-17:
> (with DISCUSS and COMMENT)
> 

[Med] We need to align the language with the RECOMMENDED in the security section (see below).

I made the following changes:

- Added a new applicability scope early in the document:

NEW:

1.3.  Applicability Scope

   0-RTT TCP Convert Protocol specified in this document SHOULD be
   used in a single administrative domain deployment model.  That
   is, the entity offering the connectivity service to a client is also
   be entity which owns and operates the Transport Converter, with no
   transit over a third-party network.

   Deployment of Transport Converters by third parties MUST adhere to
   the mutual authentication requirements in Section 9.2 to prevent
   illegitimate traffic interception (Section 9.4), in particular.

- and deleted:

OLD:
   Transport Converters can be operated by network operators or third
   parties.  Nevertheless, this document focuses on the single
   administrative deployment case where the entity offering the
   connectivity service to a client is also the entity which owns and
   operates the Transport Converter.

> strong mutual authentication scheme MUST be defined to use the Convert

[Med] Works for me. 

> conduct traffic analysis of user behavior”.

[Med] The converter has only access to part of the traffic that it is explicitly sent to it. That traffic != all the traffic from a given user. 

I went with this change:

NEW:
   Given its function and location in the network, a Transport Convert
   is in a position to observe all packets that it processes, to include
                                           ^^^^^^^^^^^^^^^^^^
   payloads and meta-data; and has the ability to profile and conduct
   some traffic analysis of user behavior.
   ^^^^

Better?

> exact practices are being suggested?  Given the RFC1812, reference,

[Med] Section 10 in general (authorization and control matters, in particular). I updated the text with a pointer to the that section. 

[Med] Will be fixed.

> Options' field.  If not, it returns an error message (Section

[Med] It returns: Unsupported TCP Option (33). Updated the text accordingly. 

> sensitive information outside a local domain.”, can you clarify what

[Med] As indicated in the text, the converter has access to sensitive data such as subscriber credentials (IMSI, for example). The converter does not insert any metadata (or any payload in general) in packets it forwards on the external realm. 

> provide an authentication/authorization solution given a certain

[Med] Fair. Will be fixed. 

> -- Section 4.4.1. Typo. s/the the/the/

[Med] Fixed. Thanks.

---

From: Roman Danyliw <[email-masked]>
Date: Sun, 22 Mar 2020 00:45:21 +0000

Hi Med!

Thanks for the updated -18 draft.  It addressed all of my concerns.  I've cleared my ballot.

Roman

-----Original Message-----
From: iesg <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, March 5, 2020 2:33 AM
To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; Michael Scharf <[email-masked]>; [email-masked]
Subject: RE: Roman Danyliw's Discuss on draft-ietf-tcpm-converters-17: (with DISCUSS and COMMENT)

Hi Roman, 

Please see inline.

Cheers,
Med

> De : Roman Danyliw via Datatracker [mailto:[email-masked]] Envoyé : 
> jeudi 5 mars 2020 05:55 À : The IESG Cc : 
> [email-masked]; [email-masked]; 
> [email-masked]; Michael Scharf; [email-masked] Objet : 
> Roman Danyliw's Discuss on draft-ietf-tcpm-converters-17:
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> ** Deployed without constraints, there would be a number of concerning 
> attacks given this protocol’s design.  Christian Huitema’s SecDir 
> review (thank you!) notes some of them.  Helpfully, this draft 
> presents various restrictive scoping to mitigate these attacks under 
> certain circumstances:
> 
> (b) Section 9.1. Furthermore, ingress filtering policies MUST be 
> enforced at the network boundaries [RFC2827].
> 
> (c) Section 9.2. The Convert Protocol is intended to be used in 
> managed networks where end hosts can be identified by their IP 
> address.
> 
> (d) Section 9.2.  Stronger mutual authentication schemes MUST be 
> defined to use the Convert Protocol in more open network environments.
> 
> Unfortunately, the protocol mechanism to operate outside of these 
> bounds is in scope because (a) and (c) include no normative language.  
> For example, this document doesn’t address converters operated by 
> third parties but it explicitly allows for their possibility with no 
> discussion of the impact.
> 
> As this is an experimental document where implementation experience 
> likely is needed for refinement, could a compromise be found with an 
> applicability statement that shrinks the threat model and provide 
> better normative guidance.
> Applicability statement: Transport Converters MUST only be deployed in 
> a single administrative domain deployment model.  The entity offering 
> the connectivity service to a client MUST also be entity which owns 
> and operates the Transport Converter, with no transit over a 
> third-party network.
> 

NEW:

1.3.  Applicability Scope

- and deleted:

OLD:

> For the Security Considerations: The Convert Protocol is RECOMMENDED 
> to be used in a managed network where end hosts can be identified by 
> their IP address.  If such control is not exerted and there is a more 
> open network environment, a strong mutual authentication scheme MUST 
> be defined to use the Convert Protocol.

[Med] Works for me. 

> 
> ** Section 9.1.  Per “Given its function and its location in the 
> network, a Transport Converter has access to the payload of all the 
> packets that it processes.”, it’s a per more than that.  It is in a 
> position to observe all packets, so that’s payload, meta-data and the 
> ability to profile and conduct traffic analysis.  Perhaps something on 
> the order of “Given its function and location in the network, a 
> Transport Convert is in a position to observe all packets, to include 
> traffic analysis of user behavior”.
> 

I went with this change:

NEW:

Better?

> ** Section 9.1.  Per “As such, it MUST be protected as a core IP 
> router (e.g., [RFC1812])”, no disagreement on the need to protect this 
> router.
> However, what
> exact practices are being suggested?  Given the RFC1812, reference, 
> what specific sections apply?
> 

> ** Section 1.2. Given that Section 4.1. outlines that the architecture 
> consists of clients, converter and servers, the language in the list 
> following “In particular, a Transport Converter achieves the following 
> :” might benefit from consistency (i.e., final target server vs. 
> server; and server vs.
> converter)
> 

[Med] Will be fixed.

> ** Section 6.2.5.  Per “Upon reception of an Extended Connect TLV, a 
> Transport Converter first checks whether it supports the TCP Options 
> listed in the 'TCP Options' field.  If not, it returns an error 
> message (Section 6.2.8).”, what error does it return?
> 

> ** Section 9.1  Per “The Transport Converter is designed to not leak 
> such sensitive information outside a local domain.”, can you clarify 
> what that means.
> 

> ** Editorially, the guidance in Section 9.2 and 9.5 needs to link 
> Section 9.2 provide an authentication/authorization solution given a 
> certain topology, and does Section 9.5.
> 

[Med] Fixed. Thanks.