Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links
Hi Danny, Luis, Qin,
Very interesting discussions on BGP communities and ALTO network maps.
To better understand the discussion, can we say that there are two settings
or models:
1. ALTO on BGP (Bottom Up)
Given BGP model (the prefixes and their associated attributes announced by
BGP communities). We do not modify this BGP model (i.e., we do not change
the prefixes announced, we do not add/remove communities announced), and we
derive ALTO models on top. For example, assume that there are multiple BGP
routers, and then ALTO can combine the views of these routers to produce a
single view. I feel that this is the essence of Danny’s proposal.
2. ALTO driven BGP (Top Down)
There is info that ALTO need, for example, to derive the cost metric for a
given cost map or ECS. The info carried by BGP is driven (at least
modified) by ALTO.
It looks that the question by Danny uses more on 1, and the example by Luis
will use more on 2. They sure can be combined. Make sense?
Richard
On Sun, Jul 9, 2023 at 11:39 AM LUIS MIGUEL CONTRERAS MURILLO <
luismiguel.contrerasmuri...@telefonica.com> wrote:
> Hi Qin, Danny,
>
>
>
> Thanks for your questions and apologies for the late response.
>
>
>
> Certainly, the way in which BGP Communities can be handled is a matter of
> development with ideas / insights from the working group.
>
>
>
> As stated in the version -01 to be submitted (available here
> https://github.com/luismcontreras/alto-bgp-communities), I do foresee the
> following way of handling BGP Communities:
>
>
>
>- In situations where a BGP Community and an ALTO PID scope the same
>grouping of prefixes, leveraging BGP Communities simplifies network
>operations by using an existing identifier for the purpose of retrieving
>ALTO information.
>
>
>
>- In situations where the purpose is to retrieve ALTO information
>applicable to a superset of PIDs, a BGP Community can be defined in order
>to group the prefixes of all those PIDs.
>
>
>
>- In situations where the purpose is to retrieve ALTO information
>applicable to a subset of prefixes across multiple PIDs, a BGP Community
>can be defined in order to group the subset of prefixes of all the PIDs.
>
>
>
>
> In summary, what I would expect is to have new network maps working with
> the concept of BGP Community as object. The prefixes associated with each
> BGP Community will be defined at BGP level. I’m considering for this
> specific operator defined communities, for instance those that have a
> geographical meaning (e.g., prefixes in Region-1 vs Region-2, commonly
> defined to being associated to peering point 1 vs 2).
>
>
>
> Hope this clarifies the questions. Anyway, more discussions are needed in
> the WG for well defining how to work with Communities, as well as to
> identify limitations, if any.
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> *De:* Qin Wu
> *Enviado el:* jueves, 6 de julio de 2023 4:18
> *Para:* Danny Lachos ; LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com>; Y. Richard Yang <
> y...@cs.yale.edu>; IETF ALTO
> *Asunto:* 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 <
> luismiguel.contre
Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links
Hi Luis, Qin, Good discussions. I see several good points: - "... 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, performance data which is related to cost map." - "... 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." In particular, we see BGP as a framework for policy checking and recursive information propagation with policy control. Given above, here are a few discussion points. The focus is on supporting ALTO deployment; that is, how to obtain ALTO-needed information from BGP as a carrier. - Use BGP communities to propagate ALTO cost metrics, for subnet, as a generalization of BGP propagating AS PATH One main data source issue in ALTO is to compute the total cost of a cost metric end-to-end, from a source to a given destination. Such information can be propagated using BGP denoted as BGP communities. The propagation will be recursive (cascading) to take advantage of BGP. BGP policies can be used to adjust the propagated values. Ideally, the information is between on-path BGP routers to achieve well-defined semantics: - the BGP node of the destination AS announces the initial cost metrics using BGP communities to a subnet prefix; - the metrics are sent upstream to the next hop BGP peer, which applies policy to decide, for each metric and each upstream, how to compute the update aggregated metric (AS path is a special case of pre-pending ASN), whether/when the info can be propagated (export policy). Looking at the current set of ALTO performance metrics, we can see that hoop count as additive; one-way delay, roundtrip delay, and delay variation as additive as a starting point; residual bw, available bw as min. The tput metric can be harder to compute and can be a topic for further investigation. There can be concerns for the model, both on protocol (scaling) and on content (privacy). For protocol scaling, the information will be more dynamic than AS path, and hence there is the concern of overhead. We can limit the information for chosen subsets; for content, BGP policies appear to be a great tool, but we should look into the details. - Use BGP community from upstream to downstream to support cascading ALTO I always feel that BGP is the right place to allow an upstream peer to notify a downstream peer whether the downstream's announcement (proposal) is accepted. This can be a good protocol design than depending on inference or measurements (e.g., see which inter-AS links carry the traffic). Is it already proposed? If so, such info can be exposed to ALTO to allow building a more complete ALTO system. These comments are particularly interesting: - "... need to maintain these two separate sessions to create the network and cost map for BGP community reachability" - "... a BGP community can span more than one physical location, thus probably new kind of cost metrics need to be elicited for characterizing the cost map" For the second case, how about cost vectors providing only partial order? That is, we do not aggregate the raw metrics (e.g., routingcost) if it is not possible (e.g., the two physical locations do not have a single policy), and provide the vector; it is a bit like BGP path has SET. Make sense? Richard On Sun, Jul 9, 2023 at 11:48 AM LUIS MIGUEL CONTRERAS MURILLO < luismiguel.contrerasmuri...@telefonica.com> wrote: > Hi Richard, Qin, > > > > Apologies for the late answer. > > > > In the particular case of Communities, we are identifying some logical > grouping of prefixes from end-users attached to the operator’s network. > This is done within conventional BGP sessions. On the other hand, with > BGP-LS we are obtaining the topological information that allows to derive > the view of how those prefixes can be reached. > > > > In summary, we need to maintain these two separate sessions to create the > network and cost map for BGP community reachability. This is an interesting > problem since a BGP community can span more than one physical location, > thus probably new kind of cost metrics need to be elicited for > characterizing the cost map. I think this can be an interesting work to be > discussed by the WG in future work. > > > > Best regards > > > > Luis > > > > *De:* Qin Wu > *Enviado el:* jueves, 6 de julio de 2023 4:52 > *Para:* Y. Richard Yang ; LUIS MIGUEL CONTRERAS MURILLO < > luismiguel.contrerasmuri...@telefonica.com> > *CC:* IETF ALTO > *Asunto:* RE: [alto] Topic B - maintenance of ALTO protocol // RE: June > 20, 2023 meeting minu
Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links
Hi Richard, Qin, Apologies for the late answer. In the particular case of Communities, we are identifying some logical grouping of prefixes from end-users attached to the operator’s network. This is done within conventional BGP sessions. On the other hand, with BGP-LS we are obtaining the topological information that allows to derive the view of how those prefixes can be reached. In summary, we need to maintain these two separate sessions to create the network and cost map for BGP community reachability. This is an interesting problem since a BGP community can span more than one physical location, thus probably new kind of cost metrics need to be elicited for characterizing the cost map. I think this can be an interesting work to be discussed by the WG in future work. Best regards Luis De: Qin Wu Enviado el: jueves, 6 de julio de 2023 4:52 Para: Y. Richard Yang ; LUIS MIGUEL CONTRERAS MURILLO CC: IETF ALTO Asunto: 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 mailto:luismiguel.contrerasmuri...@telefonica.com>> 抄送: IETF ALTO mailto:alto@ietf.org>> 主题: 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 Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la pe
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 Mee
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 rele
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
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 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 < > 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. 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 Richard, yes, but this is my personal view only, not sure if the rest have the same view. This is why I included some of the security topics in B, more related to the operation and maintenance of ALTO. Thanks Luis De: Y. Richard Yang Enviado el: martes, 27 de junio de 2023 14:56 Para: LUIS MIGUEL CONTRERAS MURILLO CC: IETF ALTO Asunto: Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links Hi Luis, On Tue, Jun 27, 2023 at 8:43 AM LUIS MIGUEL CONTRERAS MURILLO mailto:luismiguel.contrerasmuri...@telefonica.com>> wrote: Hi Richard, Thanks for your comments. Just a small comment on security. Certainly we are addressing two dimensions in ALTO regarding security, at least from my view. One is the security of ALTO itself, which I understand is part of maintenance (topic B). And the other one is the enablement of new services as the trusted networking case, as presented by Ayoub (topic C). This is at least my understanding, both are complementary and equally interesting to work on, for sure. Great clarification. So the first aspect is the focus of Topic B and the second aspect is in Topic C. Right? Richard Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relación establecida con el destinatario o con la entidad a la que está vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a privacidad@telefonica.com<mailto:privacidad@telefonica.com>. Puede consultar información adicional sobre el tratamiento de sus datos en nuestra Política de Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>. We inform you that the data controller is the Telefónica Group entity linked to the sender, for the purpose of maintaining professional contact and managing the relationship established with the recipient or with the entity to which it is linked. You may contact the data controller and exercise your rights by writing to privacidad@telefonica.com<mailto:privacidad@telefonica.com>. You may consult additional information on the processing of your data in our Privacy Policy<https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>. Informamos que o responsável pelo tratamento dos seus dados é a entidade do Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional e administrar a relação estabelecida com o destinatário ou com a entidade à qual esteja vinculado. Você pode entrar em contato com o responsável do tratamento de dados e exercer os seus direitos escrevendo a privacidad@telefonica.com<mailto:privacidad@telefonica.com>. Você pode consultar informação adicional sobre o tratamento do seus dados na nossa Política de Privacidade<https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>. ___ 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 Luis, On Tue, Jun 27, 2023 at 8:43 AM LUIS MIGUEL CONTRERAS MURILLO < luismiguel.contrerasmuri...@telefonica.com> wrote: > Hi Richard, > > > > Thanks for your comments. > > > > Just a small comment on security. Certainly we are addressing two > dimensions in ALTO regarding security, at least from my view. One is the > security of ALTO itself, which I understand is part of maintenance (topic > B). And the other one is the enablement of new services as the trusted > networking case, as presented by Ayoub (topic C). This is at least my > understanding, both are complementary and equally interesting to work on, > for sure. > Great clarification. So the first aspect is the focus of Topic B and the second aspect is in Topic C. Right? 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 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 < 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. > > > 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. > This is also a great topic for this thread. It can benefit greatly with aspects by Ayoub and team as well. Richard > 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 trust; coordinators: Ayoub, Junichi, Motoyoshi > > - D: New architectural extensions; coordinators: Roland and Sabine > > > We sure can
[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 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 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 Text IETF, ALTO Meeting: June 20, 2023 Agenda: * Transport and OAM documents * Transport: https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues * OAM: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues * ALTO Future Work: https://mailarchive.ietf.org/arch/msg/alto/uIFD6Dhikfu4J4PYcpJTbsiXbnE/ https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md * Preps for IETF 117: * Drafts and presentations that the ALTO group plans to work on * Agenda * New revision of Green Networking Metrics draft in opsawg: https://datatracker.ietf.org/doc/draft-cx-opsawg-green-metrics/ Minutes *Note taker: Richard * Charter documents: transport and OAM updates * OAM: Jensen and Med had a discussion on the draft and submit the revision to IESG. The document is now
