Re: [alto] 答复: Re: Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Roman,




Thanks for the comment.




Regarding the DRM issue, we are mostly following the guidance of RFC 7971 and 7285.




RFC 7971 (ALTO deployment considerations) has discussed the issue of information leak and RFC 7285 suggests that encryption only protects the end-to-end communication and DRM or legal agreements may be used to protect the information. In this paragraph, we are mostly considering using such mechanisms as a way to make sure the information is not leaked from the client's side.




It seems to me that the major problem is that we use normative language in the sentence. How about we rephrase the text as:




NEW:




For settings where the ALTO server and client are not in the same trust domain,

the ALTO server should reach agreements with the ALTO server on protecting

the confidentiality before granting the access to Path Vector service with sensitive

information. Such agreements may include legal contracts or Digital Right

Management (DRM) techniques.




Please let us know if that makes sense.




Best,

Kai


-----Original Messages-----
From:"Roman Danyliw" <[e-mail]>
Sent Time:2022-01-27 04:51:34 (Thursday)
To: "[e-mail]" <[e-mail]>, "Qin Wu" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "The IESG" <[e-mail]>, "[e-mail]" <[e-mail]>, "Mohamed Boucadair" <[e-mail]>
Subject: RE: 答复: Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT)



Hi Kai!

 

Thanks for the update in -20 and in particular all of the new language in the Security considerations to discuss applicability and obfuscation procedures.  Again, thanks for your patience on my reply.

 

In these edits, the following sentence was introduced into Section 11:

 

For settings where the ALTO server and client are not             

in the same trust domain, Digital Right Management (DRM) techniques          

and legal contracts protecting the sensitive Path Vector information        

MUST be applied.

 

It appears to be trying to provide guidance on how to ensure that only the expected ALTO clients get the sensitive path information in the case where the server and clients are in different trust domains.  This new language contains normative guidance to using DRM techniques.  Given this is a normative “MUST”, the specifics of “DRM techniques” is under-specified.  Independent of that, DRM techniques I quickly think of provides object security (i.e., embedding a security envelope of some form directly in the data it is trying to protect).  How would that mesh with the specified format for the path information in this document?

 

Roman

 

From: iesg <[e-mail]> On Behalf Of [e-mail]
Sent: Monday, January 3, 2022 10:44 PM
To: Qin Wu <[e-mail]>
Cc: Roman Danyliw <[e-mail]>; [e-mail]; [e-mail]; The IESG <[e-mail]>; [e-mail]; Mohamed Boucadair <[e-mail]>
Subject: Re: 答复: Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT)

 

Hi Roman and all,

 

Happy New Year!

 

We have submitted a new version of the Path Vector draft (-20) [1]. The proposed texts are integrated in Section 11. Please let us know if they address you comments.

 

Best,

Kai

 

[1] https://www.ietf.org/rfcdiff?url1=draft-ietf-alto-path-vector-19&url2=draft-ietf-alto-path-vector-20

 

 

2021-12-16 14:56:27"Qin Wu" <[e-mail]>wrote:

Hi, Roman:

It seems the leading author can not reach you via his personal email address ([e-mail]). Therefore I forward his recent reply to you.

Please help take a look at his proposed text and tell us whether it can address your comments.

 

-Qin

发件人:[e-mail] [mailto:[e-mail]]
发送时间: 2021年12月16日 9:37
收件人: Roman Danyliw <[e-mail]>
抄送: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Qin Wu <[e-mail]>; Mohamed Boucadair <[e-mail]>
主题: Re: Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT)

 

Hi Roman,

 

Please find below for the proposed text for Sec 11. Please let us know if it makes sense and any further comments or suggestions are welcomed!

 

Best,

Kai

 

-----Original Messages-----
From:[e-mail]
Sent Time:2021-12-06 22:53:04 (Monday)
To: "Roman Danyliw" <[e-mail]>
Cc: "The IESG" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT)

Hi Roman,

 

Thanks for the review and please see the replies inline.



> -----Original Messages-----
> From: "Roman Danyliw via Datatracker" <[e-mail]>
> Sent Time: 2021-11-30 23:33:54 (Tuesday)
> To: "The IESG" <[e-mail]>
> Cc: [e-mail], [e-mail], [e-mail]
> Subject: [alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-alto-path-vector-19: 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/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thanks for documenting the increased risk of exposing sensitive topology
> information and the potentially of this data being exploited for a highly
> targeted DoS attack in Section 11.  While this significant problem is
> documented, the mitigation for this fundamental issue is underspecified.  The
> security of this extension is predicated on the ANE obfuscation procedures, but
> those specifics are not provided.

>

 

 

The protection mechanisms depend heavily on what information is exposed and how

it is used. For example, for bandwidth information, the order of ANEs in a response

can be reshuffled, some even be removed, without compromising the functionality.

However, for edge server discovery, if the order of edge servers is reshuffled, the

usefulness of the information is compromised. Thus, from the extensions' perspective,

it is difficult to define a general protection mechanism without knowing the semantics of

the ANE and the objectives/constraints of the application.

 

> In my review, there doesn’t appear to be wide operational usage or
> implementations of this extension to inform these obfuscation procedures. 
> Furthermore, it appears that these procedures remain an open research question.
>  I appreciate the helpful references to the academic papers in Section 11
> ([NOVA], [RESA][ MERCATOR])  but their practical applicability to the generic
> capability provided by this extension appears to be difficulty to align and be
> caveated.  For example, [RESA] and [MERCATOR] made what appear to be
> significant assumptions on their approaches, “In this paper, we assume a
> semi-honest security model, i.e., the aggregator and all member networks will
> not deviate from the security protocol, but merely try to gather information
> during the execution of the protocol”.
> 
> I believe this document needs to be provide a stronger applicability statement
> constraining where it can be fielded and what assumptions are made about the
> trust models.  Additionally, given the uncertainty on the generic feasibility
> of obfuscation, this document should be published as experimental.

>

 

We agree that an applicability statement is needed and will propose the text asap.

Publishing the document as experiment is an option and we will discuss this with the

AD and WG chairs.

 

We have discussed with the chairs and agree that the document proceeds as

experimental.

 

OLD:

      From "For confidentiality of ALTO information, ..." to "by using minimal

      feasible region compression algorithms [NOVA] or obfuscation protocols

      [RESA][MERCATOR]."

NEW:

      For confidentiality of ALTO information, a network operator should be aware

      that this extension may introduce a new risk: the Path Vector information,

      when used together with sensitive ANE properties such as capacities of

      bottleneck links, may make network attacks easier. For example, as the Path

      Vector information may reveal more fine-grained internal network structures

      than the base protocol, an attacker may identify the bottleneck link and start a

      distributed denial-of-service (DDoS) attack involving minimal flows to conduct

      the in-network congestion. Given the potential risk of leaking sensitive

                                            ^^^^^^ the applicability statement starts here

      information, the Path Vector extension is mainly applicable in scenarios where

      1) the ANE structures and ANE properties do not impose security risks

      to the ALTO service provider, e.g., not carrying sensitive information, or 2) the

      ALTO server and client have established a reliable trust relationship, for

      example, operated in the same administrative domain, or managed by business

      partners with legal contracts.

      ^^^^^ Two cases are discussed: 1) PV does not impose security risks

      ^^^^^ e.g., not carrying sensitive information, and 2) PV carries sensitive

      ^^^^^ information between server/client of a reliable trust relationship.

 

      Three risk types are identified in Section 15.3.1 of {{RFC7285}}: (1) Excess

      disclosure of the ALTO service provider’s data to an unauthorized ALTO client;

      (2) Disclosure of the ALTO service provider's data (e.g., network topology

      information or endpoint addresses) to an unauthorized third party; and (3)

      Excess retrieval of the ALTO service provider’s data by collaborating ALTO

      clients. To mitigate these risks, an ALTO server MUST follow the guidelines in

      Section 15.3.2 of {{RFC7285}}. Furthermore, an ALTO server MUST follow

      the following additional protections strategies for risk types (1) and (3).

      ^^^^^ We revisit RFC 7285 and identify additional protections for PV.

      ^^^^^ Note that risk type (2) is not affected.

 

      For risk type (1), an ALTO server MUST use the authentication methods

      specified in Section 15.3.2 of [RFC7285] to authenticate the identify of an

      ALTO client, and apply access control techniques to restrict unprivileged

      ALTO clients from retrieving sensitive Path Vector information. For settings

      where the ALTO server and client are not in the same trust domain, Digital

      Right Management (DRM) techniques and legal contracts protecting the

      sensitive Path Vector information MUST be applied. Otherwise, the ALTO

      server MUST NOT offer the Path Vector service carrying sensitive information

      to the clients unless the potential risks are fully assessed and mitigated.

      For risk type (3), an ALTO server MUST use dynamic mappings from

      ephemeral ANE names to underlying physical entities. Thus, ANE names

      contained in the Path Vector responses to different clients or even for different

      request from the same client SHOULD point to different physical entities.

      Further, to protect the network topology from graph reconstruction (e.g.,

      through isomorphic graph identification [BONDY]), the ALTO server SHOULD

      consider protection mechanisms to reduce information exposure or obfuscate

      the real information. When doing so, the ALTO server must be aware that

      information reduction/obfuscation may lead to potential Undesirable Guidance

      from Authenticated ALTO Information risk (Section 15.2 of [RFC7285]).

 

[BONDY] J.A. Bondy, R.L. Hemminger, “Graph reconstruction—a survey”

                J. Graph Theory, 1 (1977) pp. 227–268


      Thus, implementations of ALTO servers involving reduction or obfuscation

      of the Path Vector information SHOULD consider reduction/obfuscation

      mechanisms that can preserve the integrity of ALTO information, for example,

      by using minimal feasible region compression algorithms [NOVA] or

      obfuscation protocols [RESA][MERCATOR]. However, these obfuscation

      methods are experimental and their practical applicability of these methods

                           ^^^^^ We make it clear that these obfuscation methods

                           ^^^^^ are experimental.

      to the generic capability provided by this extension is not fully assessed. The

      ALTO server MUST carefully verify that the deployment scenario satisfies the

      security assumptions of these methods before applying them to protect Path

      Vector services with sensitive network information.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to Samuel Weiler for the SECDIR review.
> 
> ** Overstatement of security properties.
> 
> Section 1.  For better confidentiality, this document aims to minimize   
> information exposure.
> 
> Section 5.1.2.  By design, ANEs are ephemeral and not to be used in further
> requests to other ALTO resources.  More precisely, the corresponding ANE names
> are no longer valid beyond the scope of the Path Vector response or the
> incremental update stream for a Path Vector request.  This has several benefits
> including better privacy of the ISPs and more flexible ANE computation.
> 
> The text in both of these sections reads to strongly.  This document defines
> the ANEs which in fact provides more detailed network information but provides
> no normative operational guidance or protocol-based protections to minimize
> (obfuscate) this information.  These claims seem to rest of practices which are
> out of scope of this document

>

 

Thanks for the comment.

 

If nothing is exposed at all, the information exposure is certainly minimal. However,

if the information must be exposed, exposing nothing will not be a valid option so

comparing with it will not make sense. Thus, the claim in section 1 that "this

document aims to minimize information exposure" is based on the condition that

"this information must be exposed". We will clarify this with the proposed text below:

 

    For better confidentiality, this document aims to minimize information exposure

    of an ALTO server when providing the Path Vector service.

 

Also the claim that "This has several benefits including better privacy of the ISPs

and more flexible ANE computation" will be revised as:

 

    Compared with globally unique ANE names, ephemeral ANE  has several

    benefits including ...

 

 

 

> ** Section 5.1.2.   Editorial
>    This has
>    several benefits including better privacy of the ISPs and more
>    flexible ANE computation.
> 

> Words are missing from this sentence – “better privacy of the ISPs” what?

 

Thanks for the comment. Please see the proposed text below:

 

    This has several benefits including better privacy of the ISP's internal structure

    and more flexible ANE computation.

 

> 
> ** Section 5.1.3.
>    Resource-constrained ALTO clients may benefit from the filtering of
>    Path Vector query results at the ALTO server ...
> 
> Can you describe the use case of these “resource-constrained ALTO clients” as
> nothing about the use cases in Section 4.2 suggested that the clients were

> constrained.

 

The term is used as in Section 4.1.2 of RFC 7285:

 

   Resource-constrained ALTO clients may benefit from the filtering of
   query results at the ALTO server.  This avoids the situation in which
   an ALTO client first spends network bandwidth and CPU cycles to
   collect results and then performs client-side filtering.
 

We will add a reference to the section.

> 

> ** Section 5.2.
> To be pedantic on what’s strictly in C++:
> 
> OLD
> For
> example, in programming languages such as C++, a Path Vector will
> have the type of JSONArray<ANEName>.
> 
> NEW
> For example, in programming languages such as C++ where there existed a JSON
> array type named JSONArray, a Path Vector will have the type of
> JSONArray<ANEName>.

>

Thanks for the proposed text and we will adopt it in the next revision.

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