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

[Roman Danyliw <[e-mail]>]

Hi Med!

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

Roman

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

Hi Roman, 

Thank you for the review.

Please see inline.

Cheers,
Med

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

[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.


> 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 
> payloads and meta-data; and has the ability to profile and 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?


> ** 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?
> 

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

> 
> ----------------------------------------------------------------------
> 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)
> 

[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?
> 

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


> ** 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.
> 

[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. 


> ** 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] Fair. Will be fixed. 

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

[Med] Fixed. Thanks. 

>