Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links
Luis: Regarding isolation of the ALTO server from direct client interaction, do we have a scenario where one or multiple intermediate server is placed between the client and ALTO server. Or do we have the case where ALTO information will be distributed through a collection of intermediate servers before reaching the client? Second question, Javascript Object Signing and Encryption (jose) has been well specified in JOSE WG, I am wondering how ALTO JSON object can be translated into JOSE object to provide better security enhancement? -Qin 发件人: alto [mailto:alto-boun...@ietf.org] 代表 LUIS MIGUEL CONTRERAS MURILLO 发送时间: 2023年6月27日 5:14 收件人: Y. Richard Yang ; IETF ALTO 主题: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links Hi all, Related to Topic B on maintenance of ALTO, as a way of summary of what has been discussed during the last weeks, we could have two major sub-topics: 1/ extension of ALTO to consider operational simplicity. Here fits the proposal of introducing BGP communities in ALTO. The rationale is that operators use BGP communities quite often as mechanism for applying policies and determining certain behaviors on the IP addresses grouped in the form of communities. This seems quite useful as well at the time of exposing associated information (metrics, topology, etc) as enabled by ALTO. An initial draft can be found here: https://github.com/luismcontreras/alto-bgp-communities The plan is to generate version -01 for IETF 117. 2/ security aspects of ALTO. This has been discussed in both one of the interim meetings (see https://datatracker.ietf.org/meeting/interim-2023-alto-05/materials/slides-interim-2023-alto-05-sessa-security-aspects-regarding-alto-luis-00) and one ad-hoc discussion meeting (https://mailarchive.ietf.org/arch/msg/alto/HnhO5H5xy4hBGtfm3JI7-K9mq3Y/). The rationale for this activity is to improve the security around the deployment and operation of ALTO in production networks. As commented during the interim, there are a number of security issues documented so far, like: · A high-level discussion of security issues in the ALTO problem statement [RFC5693] · Unwanted information disclosure risks, as well as specific security-related requirements in the ALTO requirements document [RFC6708]. · Issues related ALTO server discovery in [RFC7286] · Identified cases for ALTO deployments in [RFC7971] · Security considerations in the remaining RFCs However, new security concerns emerge from deployments, such as: · Obfuscation of PIDs, and the handling of them in scenarios with multiple ALTO clients · Mechanisms for isolation of the ALTO server from direct client interaction · Secure retrieval of information from external components (e.g., probes, etc) · etc A potential first step could be to document these new security considerations and then concentrate on those not solved representing relevant threats in ALTO operation. There could be other relevant topics related to the maintenance of ALTO part from the two commented above. Any further ideas on this respect? Of course for those interested on the topics above, please comment. Thanks in advance Best regards Luis De: alto mailto:alto-boun...@ietf.org>> En nombre de Y. Richard Yang Enviado el: miércoles, 21 de junio de 2023 1:47 Para: IETF ALTO mailto:alto@ietf.org>> Asunto: [alto] June 20, 2023 meeting minutes and discussion working links Hi all, As suggested by Ayoub, Jordi and others during the weekly meeting today, starting from today, the note taker will not only update the meeting minutes page (https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2023.md), but also provide a text summary and comments, if appropriate, on the meeting. So below are my quick comments and the full meeting minutes are below; the archive is at the link above. Regarding comments, the most important item that I, as a note taker, take away is the wonderful discussion about how to organize future work discussions. In particular, the participants divided the potential work into 4 areas, and created 4 github issues. We also created a common Google doc to allow systematic write up. The links to them are below. In particular, the four areas and their coordinators are: - A: Integration of data sources and their exposures; coordinator: Jordi, Luis and Kai - B: Maintenance of ALTO protocol; coordinator: Luis, Richard - C: Security and trust; coordinators: Ayoub, Junichi, Motoyoshi - D: New architectural extensions; coordinators: Roland and Sabine We sure can adjust the coordinators. So so, please let me know, and we can adjust the page. The plan is that the coordinators will closely with the chairs (Qin and Med) to make concrete progress. The coordinators will kick off the discussions. Richard as note taker on June 20, 2023 Meeting Minutes
Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links
Hi, Richard, Luis: 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Y. Richard Yang 发送时间: 2023年6月27日 21:00 收件人: LUIS MIGUEL CONTRERAS MURILLO 抄送: IETF ALTO 主题: Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links On Tue, Jun 27, 2023 at 8:33 AM Y. Richard Yang mailto:y...@cs.yale.edu>> wrote: Hi Luis, Thank you so much for starting this thread on Topic B. I feel that this is a crucial topic for the WG to investigate. Please see below. On Mon, Jun 26, 2023 at 5:18 PM LUIS MIGUEL CONTRERAS MURILLO mailto:luismiguel.contrerasmuri...@telefonica.com>> wrote: Hi all, Related to Topic B on maintenance of ALTO, as a way of summary of what has been discussed during the last weeks, we could have two major sub-topics: 1/ extension of ALTO to consider operational simplicity. Here fits the proposal of introducing BGP communities in ALTO. The rationale is that operators use BGP communities quite often as mechanism for applying policies and determining certain behaviors on the IP addresses grouped in the form of communities. This seems quite useful as well at the time of exposing associated information (metrics, topology, etc) as enabled by ALTO. An initial draft can be found here: https://github.com/luismcontreras/alto-bgp-communities The plan is to generate version -01 for IETF 117. I like this subtopic! I have adopted a view that ALTO should be divided into 2 layers: a concept/abstraction layer and a transport layer built on top of the concept layer. I feel that there is great work validating the concept layer, for example, the concepts of distance, ranking, say in the flow director, padis work. For transport later, the WG can be flexible and provide multiple transport mechanisms. BGP communities are an excellent, well defined framework to serve as a transport (of both existing alto concepts/abstractions) and also existing networking abstractions). Good direction. To be specific, I think it will be a worthwhile effort to look into BGP-ALTO; that is, how to use BGP to encode, transport and update ALTO basic information. It can be considered a BGP vertical slice, with BGP-LS as the lower lower layer. Make sense? I will add some more details to the doc. Talk to many of you soon. [Qin Wu] As we know, BGP-LS is used to collect the network topology data, ALTO is used to expose the network topology information, RFC7752 has already provided ALTO and BGP-LS integration use case in figure 3: ++ | Client |<--+ ++ | |ALTO++ BGP with+-+ ++ | Protocol | ALTO | Link-State NLRI | BGP | | Client |<--+| Server |<| Speaker | ++ ||| | | |++ +-+ ++ | | Client |<--+ ++ Figure 3: ALTO Server Using Network Topology Information Network topology data carried in BGP-LS is modelled as node, link , prefix ALTO network information resource is modelled as Network map, Cost map, property map, entity property map, We need to explore how node, link information combing with next hop information, inter-AS link information carried in BGP-LS Is transformed into network map, cost map, property map, etc, I feel this is the missing pieces we take for granted, in addition, we need to consider how network topology can be correlated with other network data, e.g., Performance data which is related to cost map. Richard ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links
Hi, Danny:
BGP community can be seen as a tag attached to the BGP routes exchanged between
two BGP peers.
It is interesting to see ALTO network map can be generated based on
BGP-communities, two questions I want to ask here:
1. We have many common BGP communities, e.g., local AS community, route
target community, route origin community, do you think all these communities
can be used to generate network map
2. For network map, we usually map IP addresses to PIDs, e.g.,
"network-map" : {
"PID0" : { "ipv6" : [ "::/0" ] },
"PID1" : { "ipv4" : [ "0.0.0.0/0" ] },
"PID2" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/24" ] },
"PID3" : { "ipv4" : [ "192.0.2.0/25", "192.0.2.128/25" ] }
}
So when we introduce communities, do you think such mapping should be
modified, replaced? What format will looks like?
e.g., should establish the mapping between PIDs and community or should
we define the network map other than ipv4/ipv6 network map?
-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Danny Lachos
发送时间: 2023年7月5日 15:59
收件人: LUIS MIGUEL CONTRERAS MURILLO
; Y. Richard Yang
; IETF ALTO
主题: Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023
meeting minutes and discussion working links
Hi Luis,
Thanks for starting this thread
See a quick comment below:
1/ extension of ALTO to consider operational simplicity. Here fits the proposal
of introducing BGP communities in ALTO. The rationale is that operators use BGP
communities quite often as mechanism for applying policies and determining
certain behaviors on the IP addresses grouped in the form of communities. This
seems quite useful as well at the time of exposing associated information
(metrics, topology, etc) as enabled by ALTO. An initial draft can be found
here: https://github.com/luismcontreras/alto-bgp-communities
The plan is to generate version -01 for IETF 117.
Regarding the use of BGP information (including BGP communities), I was
wondering how to process this data. Should it be considered an aggregation
process?
This is because tons of data will eventually be received, and in this case, the
BGP routing information could be aggregated into subnet prefixes grouped by
their attributes (Communities, BGP nextHop, etc.).
This process will massively compress the BGP data and then this re-structured
and aggregated data could be used to generate, for instance, ALTO network maps
based on BGP-Communities.
Make sense?
On 26.06.23 23:13, LUIS MIGUEL CONTRERAS MURILLO wrote:
Hi all,
Related to Topic B on maintenance of ALTO, as a way of summary of what has been
discussed during the last weeks, we could have two major sub-topics:
1/ extension of ALTO to consider operational simplicity. Here fits the proposal
of introducing BGP communities in ALTO. The rationale is that operators use BGP
communities quite often as mechanism for applying policies and determining
certain behaviors on the IP addresses grouped in the form of communities. This
seems quite useful as well at the time of exposing associated information
(metrics, topology, etc) as enabled by ALTO. An initial draft can be found
here: https://github.com/luismcontreras/alto-bgp-communities
The plan is to generate version -01 for IETF 117.
2/ security aspects of ALTO. This has been discussed in both one of the interim
meetings (see
https://datatracker.ietf.org/meeting/interim-2023-alto-05/materials/slides-interim-2023-alto-05-sessa-security-aspects-regarding-alto-luis-00)
and one ad-hoc discussion meeting
(https://mailarchive.ietf.org/arch/msg/alto/HnhO5H5xy4hBGtfm3JI7-K9mq3Y/). The
rationale for this activity is to improve the security around the deployment
and operation of ALTO in production networks. As commented during the interim,
there are a number of security issues documented so far, like:
1. A high-level discussion of security issues in the ALTO problem
statement [RFC5693]
2. Unwanted information disclosure risks, as well as specific
security-related requirements in the ALTO requirements document [RFC6708].
3. Issues related ALTO server discovery in [RFC7286]
4. Identified cases for ALTO deployments in [RFC7971]
5. Security considerations in the remaining RFCs
However, new security concerns emerge from deployments, such as:
1. Obfuscation of PIDs, and the handling of them in scenarios with
multiple ALTO clients
2. Mechanisms for isolation of the ALTO server from direct client
interaction
3. Secure retrieval of information from external components (e.g.,
probes, etc)
4. etc
A potential first step could be to document these new security considerations
and then concentrate on those not solved representing relevant threats in ALTO
operation.
There could be other relevant topics related to the maintenance of ALTO part
from the two commented above.
Any further ideas on this respect?
Of course for those interested on the
Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links
Hi Luis, Thanks for starting this thread See a quick comment below: 1/ extension of ALTO to consider operational simplicity. Here fits the proposal of introducing BGP communities in ALTO. The rationale is that operators use BGP communities quite often as mechanism for applying policies and determining certain behaviors on the IP addresses grouped in the form of communities. This seems quite useful as well at the time of exposing associated information (metrics, topology, etc) as enabled by ALTO. An initial draft can be found here:https://github.com/luismcontreras/alto-bgp-communities The plan is to generate version -01 for IETF 117. Regarding the use of BGP information (including BGP communities), I was wondering how to process this data. Should it be considered an aggregation process? This is because tons of data will eventually be received, and in this case, the BGP routing information could be aggregated into subnet prefixes grouped by their attributes (Communities, BGP nextHop, etc.). This process will massively compress the BGP data and then this re-structured and aggregated data could be used to generate, for instance, ALTO network maps based on BGP-Communities. Make sense? On 26.06.23 23:13, LUIS MIGUEL CONTRERAS MURILLO wrote: Hi all, Related to Topic B on maintenance of ALTO, as a way of summary of what has been discussed during the last weeks, we could have two major sub-topics: 1/ extension of ALTO to consider operational simplicity. Here fits the proposal of introducing BGP communities in ALTO. The rationale is that operators use BGP communities quite often as mechanism for applying policies and determining certain behaviors on the IP addresses grouped in the form of communities. This seems quite useful as well at the time of exposing associated information (metrics, topology, etc) as enabled by ALTO. An initial draft can be found here:https://github.com/luismcontreras/alto-bgp-communities The plan is to generate version -01 for IETF 117. 2/ security aspects of ALTO. This has been discussed in both one of the interim meetings (see https://datatracker.ietf.org/meeting/interim-2023-alto-05/materials/slides-interim-2023-alto-05-sessa-security-aspects-regarding-alto-luis-00) and one ad-hoc discussion meeting (https://mailarchive.ietf.org/arch/msg/alto/HnhO5H5xy4hBGtfm3JI7-K9mq3Y/). The rationale for this activity is to improve the security around the deployment and operation of ALTO in production networks. As commented during the interim, there are a number of security issues documented so far, like: * A high-level discussion of security issues in the ALTO problem statement [RFC5693] * Unwanted information disclosure risks, as well as specific security-related requirements in the ALTO requirements document [RFC6708]. * Issues related ALTO server discovery in [RFC7286] * Identified cases for ALTO deployments in [RFC7971] * Security considerations in the remaining RFCs However, new security concerns emerge from deployments, such as: * Obfuscation of PIDs, and the handling of them in scenarios with multiple ALTO clients * Mechanisms for isolation of the ALTO server from direct client interaction * Secure retrieval of information from external components (e.g., probes, etc) * etc A potential first step could be to document these new security considerations and then concentrate on those not solved representing relevant threats in ALTO operation. There could be other relevant topics related to the maintenance of ALTO part from the two commented above. Any further ideas on this respect? Of course for those interested on the topics above, please comment. Thanks in advance Best regards Luis *De:* alto *En nombre de * Y. Richard Yang *Enviado el:* miércoles, 21 de junio de 2023 1:47 *Para:* IETF ALTO *Asunto:* [alto] June 20, 2023 meeting minutes and discussion working links Hi all, As suggested by Ayoub, Jordi and others during the weekly meeting today, starting from today, the note taker will not only update the meeting minutes page (https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2023.md), but also provide a text summary and comments, if appropriate, on the meeting. So below are my quick comments and the full meeting minutes are below; the archive is at the link above. Regarding comments, the most important item that I, as a note taker, take away is the wonderful discussion about how to organize future work discussions. In particular, the participants divided the potential work into 4 areas, and created 4 github issues. We also created a common Google doc to allow systematic write up. The links to them are below. In particular, the four areas and their coordinators are: - A: Integration of data sources and their exposures; coordinator: Jordi, Luis and Kai - B: Maintenance of ALTO protocol; coordinator: Luis, Richard - C: Security and
