6.  Security Considerations

   As an extension of the base ALTO protocol [RFC7285], this document
   fits into the architecture of the base protocol, and hence the
   Security Considerations (Section 15) of the base protocol fully apply
   when this extension is provided by an ALTO server.  For example, the
   same authenticity and integrity considerations (Section 15.1 of
   [RFC7285]) still fully apply; the same considerations for the privacy
   of ALTO users (Section 15.4 of [RFC7285]) also still fully apply.

   The calendaring information provided by this extension requires
   additional considerations on three security considerations discussed
   in the base protocol: potential undesirable guidance to clients
   (Section 15.2 of [RFC7285]), confidentiality of ALTO information
   (Section 15.2 of [RFC7285]), and availability of ALTO (Section 15.5
   of [RFC7285]).  For example, by providing network information in the
   future in a calendar, this extension may improve availability of
   ALTO, when the ALTO server is unavailable but related information is
   already provided in the calendar.

   [Dawn]: The confidentiality of ALTO information is in Section 15.3 of [RFC7285].

   For confidentiality of ALTO information, an operator should be
   cognizant that this extension may introduce a new risk: an ALTO
   client may get information for future events that are scheduled
   through calendaring.  Possessing such information, the client may use
   it to achieve its goal: (1) initiating connections only at
   advantageous network costs, leading to unexpected network load; (2)
   generating massive connections to the network at times where its load
   is expected to be high.

   To mitigate this risk, the operator should address the risk of ALTO
   information being leaked to malicious clients or third parties.  As
   specified in Section 15.3.2 ("Protection Strategies") of [RFC7285],
   the ALTO server should authenticate ALTO clients and use the
   Transport Layer Security (TLS) protocol so that Man In The Middle
   (MITM) attacks to intercept an ALTO Calendar are not possible.
   [RFC7285] ensures the availability of such a solution in its
   Section 8.3.5.  "Authentication and Encryption", which specifies that
   "ALTO server implementations as well as ALTO client implementations
   MUST support the "https" URI scheme [RFC2818] and Transport Layer
   Security (TLS) [RFC5246].
 
   [Dawn]: "Man In The Middle (MITM) attacks" is preferred to be "Man-in-the-middle (MITM) attacks"
   [Dawn] To be consistent, texts "to intercept an ALTO Calendar are not possible" can be adjusted to "to intercept ALTO Cost Calendar information are not possible". 
  
Randriamasy, et al.      Expires January 3, 2019               [Page 24]

Internet-Draft             ALTO Cost Calendar                  July 2018


   For potential undesirable guidance of ALTO information, an ALTO
   client should be cognizant that using calendaring information can
   have risks: (1) a repeat pattern may be only statistical, and (2)
   future events may change.  Hence, a more robust ALTO client should
   adapt and extend protection strategies specified in Section 15.2 of
   the base protocol: it should develop self check and also ensure
   information update, to reduce the impact of this risk.

   [Dawn]: For the structure of these paragraphs, as you mentioned that three parts of Security Considerations are expanded (potential undesirable guidance to clients, confidentiality of ALTO information and availability of ALTO). My suggestion for the following paragraphs is to follow the sequence of these three parts. That is, the sequence introducing each new expanded issues should be: potential undesirable guidance to clients -> confidentiality of ALTO information -> Availability of ALTO.

7.  Operational Considerations

   Conveying ALTO Cost Calendars tends to reduce the on-the-wire data
   exchange volume compared to multiple single cost ALTO transactions,
   as an application has a set of time-dependent values upon which it
   can plan its connections in advance with no need for the ALTO Client
   to query information at each time.  Additionally, the Calendar
   response attribute "repeated", when provided, saves additional data
   exchanges in that it indicates that the ALTO Client does not need to
   query Calendars during a period indicated by this attribute.

   [Dawn]: Also, to keep consistent, the last sentence of this paragraph "query Calendars during a period indicated by this attribute" can be specified to "query ALTO Cost Calendars during a period indicated by this attribute" since Calendar in the sentence is capitalized.