]> Arrcus, Inc

2077 Gateway Place, Suite 400 San Jose CA 95110 US mjethanandani@gmail.com

Arrcus, Inc

2077 Gateway Place, Suite 400 San Jose CA 95110 US derek@arrcus.com

Arrcus, Inc

301 Midenhall Way Cary NC 27513 US acee.ietf@gmail.com

Equinix, Inc

CA reshad@yahoo.com

Individual

US nicolas@strina.net

Routing Link State Routing IGP IS-IS OSPF OSPFv2 OSPFv3 TWAMP STAMP BGP-LS measurement discovery This document defines IGP capability advertisements for measurement group membership for Active Measurement Protocols (AMPs) such as TWAMP and STAMP. An IS-IS capability sub-TLV is defined for IS-IS and an OSPF Router Information (RI) LSA TLV is defined for OSPFv2 and OSPFv3. The mechanism allows IGP routers to discover other routers participating in different measurement groups, enabling automatic discovery of measurement endpoints throughout an IS-IS or OSPF routing domain. The solution uses a Group ID to identify measurement group membership, where the same interface address (IPv4 or IPv6) may be used for multiple measurement groups. A corresponding BGP - Link State (BGP-LS) node-level attribute is defined to distribute measurement group membership beyond a single IGP domain.

Introduction In network deployments, different IGP routers may participate in different measurement groups for various purposes. For example, one measurement group may be used for TWAMP (Two-Way Active Measurement Protocol) , another for STAMP (Simple Two-Way Active Measurement Protocol) , and yet another for other operational purposes. To enable automatic discovery and configuration of these measurement groups, there is a need for IGP routers to discover which other routers are participating in which measurement groups. This discovery mechanism must work whether or not the participating routers are in the same IS-IS level or OSPF area, which implies that the membership information must be flooded domain-wide. This document defines an IS-IS capability sub-TLV and an OSPF Router Information (RI) LSA TLV, similar to the seamless BFD discriminator mechanisms defined in and , that allow routers to advertise their measurement group membership. The OSPF encoding is applicable to both OSPFv2 and OSPFv3 . The mechanism uses Group ID to identify measurement group membership, where the interface address (IPv4 or IPv6) may be associated with either a physical interface or a loopback interface. The same interface address may be used to indicate membership in multiple measurement groups.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the following terms:

Active Measurement Protocol (AMP):

A protocol used to actively measure performance between two IP endpoints, for example TWAMP or STAMP .

Active Measurement Group (AMG):

A set of IP endpoints that are configured to perform active measurement with one another using a single AMP, a single IP address family, and, optionally, a set of non-default AMP parameters. An AMG is identified by a Group ID and is configured within a single administrative domain. Separate AMGs are used for different AMPs and for different address families.

Group ID:

The 2-octet identifier of an AMG, in the range 1 through 65534. A distinct Group ID is required for each AMG within the administrative domain in which the AMGs are configured.

IP endpoint (endpoint):

An IPv4 or IPv6 interface address, associated with either a physical interface or a loopback interface, through which a router participates in one or more AMGs.

AMP session:

A measurement session established between two IP endpoints of a given AMG, using the AMP associated with that AMG. An AMP session is identified by the AMG and the pair of IP endpoints.

Administrative domain:

The scope within which AMGs and their Group IDs are configured consistently. This is normally a single IGP domain; see .

The IS-IS Router CAPABILITY TLV, its S and D flags, and the associated elements of procedure are as specified in . The OSPF Router Information (RI) LSA, its flooding scopes, its multiple instances, and the associated elements of procedure are as specified in . In this document, "IGP" is used when the text applies to IS-IS, OSPFv2, and OSPFv3. "OSPF" is used when the text applies to both OSPFv2 and OSPFv3; OSPFv2 or OSPFv3 is used when the text is specific to one of the two protocols.

Use Case At a high level, different IGP routers participate in different measurement groups. For example, measurement group 1 may be used for TWAMP, measurement group 2 for STAMP, and measurement group 3 for another purpose. The requirements for measurement group discovery are:

• IGP routers need to discover which routers are participating in which measurement groups.
• Discovery must work whether or not the participating routers are in the same IS-IS level or OSPF area, which implies that the membership information must be flooded domain-wide.
• A Group ID is used to identify the membership of a particular measurement group.
• The interface address can be associated with either a physical interface or a loopback interface.
• The same interface address (IPv4 or IPv6) can be used for multiple measurement groups.
• Unique active measurement parameters may be associated with a measurement group. For example, a different STAMP UDP port and minimum receive interval can be associated with a measurement group allowing IGP routers in the same measurement group to use non-default parameter values. Distribution of these parameters is out of scope for this document; see .
• AMG membership should be discoverable across IGP domains.

Active Measurement Groups Each AMG supported by an IGP router is identified by a Group ID. Each AMG has an associated IP endpoint, AMP, and IP address family. IGP routers will discover measurement partners in common AMGs identified by Group ID and attempt to establish AMP sessions in the AMG. Additionally, unique non-default parameters may be associated with an AMP. For example, the UDP ports supported by STAMP may be associated with an AMG. AMGs and their Group IDs are configured within a single administrative domain. This is normally a single IGP domain unless inter-domain discovery is required (refer to ). Each AMG will have an associated AMP and optionally non-default parameters associated with the AMG. The AMP and non-default parameters are not advertised in the IGPs as the protocol extensions specified herein are solely to discover the IP endpoints participating in the AMG. Assuring consistent configuration of the AMP and associated non-default AMP parameters is beyond the scope of this specification. Distinct AMGs are required for distinct AMPs and for distinct IP address families. It is understood that unique AMGs will also be required for unique permutations of asymmetric non-default parameters (e.g., different UDP ports for STAMP endpoints). However, this is not seen as the predominant use case.

IS-IS AMP Measurement Group Sub-TLV Since loopback support is required, and there is no adjacency created over loopback interfaces to carry Application Specific Link Attribute (ASLA) information, the solution defines an IS-IS capability sub-TLV similar to seamless BFD discriminators . This approach allows the advertisement of measurement group membership information in the Router CAPABILITY TLV, which is flooded domain-wide. This document defines a new IS-IS capability sub-TLV for advertising AMP measurement group membership. The sub-TLV is carried in the IS-IS Router CAPABILITY TLV (TLV 242) as defined in . The AMP Measurement Group sub-TLV has the following format:

AMP Measurement Group sub-TLV Format

Fields:

Type:

TBD1 (to be assigned by IANA, see )

Length:

1 octet. The length of the value field in octets. The address family will be inferred from the length of the sub-TLV. For IPv4 addresses, the length MUST be 6. For IPv6 addresses, the length MUST be 18. A sub-TLV with a length other than 6 or 18 MUST be considered malformed. Consistent with the handling of unsupported sub-TLVs in Section 4 of , a receiving router MUST silently ignore such a sub-TLV and MUST continue processing the other sub-TLVs carried in the Router CAPABILITY TLV.

Group ID:

2 octets. Group ID used to associate the endpoint's membership with other routers in the AMG. An IS-IS router can advertise multiple AMP Measurement Group sub-TLVs with different Group IDs. Each AMG is associated with a single AMP and a single IP address family, so a distinct Group ID is required for each AMG within the administrative domain. The Group ID values 0 and 65535 are reserved and MUST NOT be used to identify an AMG; the range of Group IDs available to identify an AMG is 1 through 65534. A router MUST ignore an AMP Measurement Group sub-TLV advertising a reserved Group ID. These values are reserved for possible future definition of well-known Group IDs; no such Group IDs are defined by this document.

IPv4/IPv6 Endpoint Address:

4 octets for IPv4 or 16 octets for IPv6. The interface address (IPv4 or IPv6) that identifies this endpoint's usage in the measurement group indicated by the Group ID. This address MAY be associated with a physical interface or a loopback interface.

Multiple instances of this sub-TLV MAY be included in the Router CAPABILITY TLV, each advertising the membership of one IP endpoint in one AMG. The AMP associated with an AMG is not carried in the sub-TLV; it is determined from the local configuration of the AMG identified by the Group ID, as described in . Since an AMG is associated with a single IP address family, all AMP Measurement Group sub-TLVs advertising a given Group ID MUST carry an endpoint address of that AMG's address family; a sub-TLV whose endpoint address family does not match that of the AMG identified by the Group ID MUST be ignored. Within a single Router CAPABILITY TLV, if multiple sub-TLVs have the same Group ID and IP endpoint, only the first is used. Since two such sub-TLVs convey identical membership information, this has no effect on the resulting measurement group membership. Section 3 of leaves the choice undefined when a receiving system holds two copies of a Router CAPABILITY TLV from the same system with conflicting information for a given sub-TLV; no additional procedure is defined here. The AMP Measurement Group sub-TLV MUST be advertised in an IS-IS Router CAPABILITY TLV with the S flag set, so that the TLV is flooded across the entire routing domain as specified in Section 2 of . As specified in Section 3 of , a router advertising capabilities with different flooding scopes originates a separate Router CAPABILITY TLV for each scope; consequently, the AMP Measurement Group sub-TLV MUST NOT be advertised in a Router CAPABILITY TLV with the S flag clear. A receiving router processes the sub-TLV as described in , subject to the elements of procedure in Section 3 of . Leaking of the Router CAPABILITY TLV between IS-IS levels, including the setting of the D bit when the TLV is leaked from Level 2 to Level 1 and the prohibition on leaking a TLV with the D bit set from Level 1 to Level 2, is performed as specified in Sections 2 and 3 of . This document defines no additional leaking procedures. As specified in Section 4 of , a router performing the leaking leaks the entire Router CAPABILITY TLV without change even if it does not support the AMP Measurement Group sub-TLV; a leaking router therefore MUST NOT remove AMP Measurement Group sub-TLVs from a TLV it leaks. As specified in Section 2 of , a single IS-IS Router CAPABILITY TLV carries at most 250 octets of sub-TLVs, and more than one Router CAPABILITY TLV from the same source may be present. A router with more measurement group memberships than will fit in one TLV MUST advertise additional instances of the Router CAPABILITY TLV, each with the S flag set. A receiving router MUST process the AMP Measurement Group sub-TLVs carried in all such instances as a single set of advertisements. See for the multi-part TLV semantics corresponding to the MP value registered in .

OSPF AMP Measurement Group TLV For the same reasons described in , i.e., an endpoint address may be a loopback address over which no adjacency, and consequently no Application Specific Link Attribute (ASLA) advertisement, exists, the OSPF solution advertises measurement group membership in the OSPF Router Information (RI) LSA . This is analogous to the advertisement of S-BFD discriminators in OSPF . This document defines a new OSPF RI LSA TLV, the AMP Measurement Group TLV, for advertising AMP measurement group membership. The TLV is applicable to both OSPFv2 and OSPFv3 . It is carried in the OSPFv2 RI Opaque LSA (Opaque type 4) or the OSPFv3 RI LSA (LSA function code 12) as specified in , and its format follows the OSPF RI LSA TLV format specified in Section 2.3 of . The AMP Measurement Group TLV has the following format:

AMP Measurement Group TLV Format

Fields:

Type:

2 octets. TBD2 (to be assigned by IANA, see )

Length:

2 octets. The length of the value field in octets. The address family is inferred from the length of the TLV. For IPv4 endpoint addresses, the length MUST be 8. For IPv6 endpoint addresses, the length MUST be 20. Since both lengths are a multiple of 4 octets, no TLV padding is required. A TLV with a length other than 8 or 20 MUST be considered malformed. A receiving router MUST ignore such a TLV and MUST continue processing the other TLVs carried in the RI LSA, consistent with the handling of unrecognized TLVs in Section 2.3 of .

Group ID:

2 octets. Group ID used to associate the endpoint's membership with other routers in the AMG. The semantics, reserved values, and range of the Group ID are as specified for the IS-IS AMP Measurement Group sub-TLV in . An OSPF router can advertise multiple AMP Measurement Group TLVs with different Group IDs. A router MUST ignore an AMP Measurement Group TLV advertising a reserved Group ID.

Reserved:

2 octets. This field MUST be set to zero on transmission and MUST be ignored on receipt. It is present so that the endpoint address is 4-octet aligned within the TLV.

IPv4/IPv6 Endpoint Address:

4 octets for IPv4 or 16 octets for IPv6. The interface address (IPv4 or IPv6) that identifies this endpoint's usage in the measurement group indicated by the Group ID. This address MAY be associated with a physical interface or a loopback interface. An IPv4 endpoint address MAY be advertised by an OSPFv3 router and an IPv6 endpoint address MAY be advertised by an OSPFv2 router since the endpoint address identifies an AMP endpoint and is independent of the address family of the advertising OSPF instance.

Multiple instances of this TLV MAY be included in the RI LSA, each advertising the membership of one IP endpoint in one AMG. The AMP associated with an AMG is not carried in the TLV; it is determined from the local configuration of the AMG identified by the Group ID, as described in . Since an AMG is associated with a single IP address family, all AMP Measurement Group TLVs advertising a given Group ID MUST carry an endpoint address of that AMG's address family; a TLV whose endpoint address family does not match that of the AMG identified by the Group ID MUST be ignored. If multiple TLVs advertised by the same OSPF router have the same Group ID and IP endpoint, only the first is used. Since two such TLVs convey identical membership information, this has no effect on the resulting measurement group membership. As specified in Section 2.7 of , the flooding scope rules for an RI LSA TLV are specified on a per-TLV basis. Since the membership information must be flooded domain-wide, the AMP Measurement Group TLV MUST be advertised in an AS-scoped RI LSA, i.e., an OSPFv2 Opaque LSA of type 11 or an OSPFv3 RI LSA with the S1 bit clear and the S2 bit set. AS-scoped LSAs are not flooded into stub areas or Not-So-Stubby Areas (NSSAs). Consequently, and as described in Section 2.7 of , a router attached to one or more stub areas or NSSAs SHOULD additionally advertise the same AMP Measurement Group TLVs in an area-scoped RI LSA, i.e., an OSPFv2 Opaque LSA of type 10 or an OSPFv3 RI LSA with the S1 bit set and the S2 bit clear, in each such area. The AMP Measurement Group TLV MUST NOT be advertised in a link-scoped RI LSA. Section 3 of requires that the processing of a TLV advertised in multiple RI LSA instances be specified in the document defining that TLV. A router with more measurement group memberships than will fit in a single RI LSA MUST advertise additional RI LSA instances, as specified in , with the same flooding scope. The AMP Measurement Group TLVs advertised by an OSPF router for a given flooding scope are the union of the AMP Measurement Group TLVs in all the non-MaxAge RI LSA instances advertised by that router with that flooding scope, and a receiving router MUST process them as a single set of advertisements. A change in the information advertised in the AMP Measurement Group TLV MUST NOT trigger an SPF computation at a receiving router.

Operations A router that participates in one or more AMGs MUST advertise its AMG membership. An IS-IS router MUST advertise the AMP Measurement Group sub-TLV in its Router CAPABILITY TLV as specified in , and an OSPF router MUST advertise the AMP Measurement Group TLV in its RI LSA as specified in . For each IP endpoint that participates in an AMG, the router MUST include an instance of the sub-TLV or TLV with the Group ID corresponding to that AMG. If an endpoint participates in AMGs associated with different AMPs (e.g., one AMG for TWAMP and another for STAMP), the router advertises one sub-TLV or TLV instance per AMG, each with the corresponding Group ID. The protocols themselves are not advertised. An AMP session is identified by the AMG and the pair of IP endpoints between which it is established. A router MUST NOT establish more than one AMP session for a given AMG between the same pair of IP endpoints. Where two routers have IP endpoints in more than one common AMG, a separate AMP session is established for each such AMG, since distinct AMGs may be associated with distinct AMPs or with distinct non-default AMP parameters. A router MUST NOT use an AMP Measurement Group sub-TLV carried in a Router CAPABILITY TLV that, per Section 3 of , is not to be used: that is, one present in an LSP of a system that is not currently reachable via Level x paths, where "x" is the level in which the sending system advertised the TLV, or one whose Router ID is 0.0.0.0 with no IPv6 TE Router ID sub-TLV present. Where an AMP session has already been established as a result of such an advertisement, the receiving router SHOULD tear the session down. Similarly, an OSPF router MUST NOT use an AMP Measurement Group TLV advertised in an RI LSA when the router that originated the LSA is not reachable via OSPF-calculated paths. For an area-scoped RI LSA, the originating router must be reachable in the area in which the LSA was received. For an AS-scoped RI LSA originated by a router in a remote area, the reachability determination described in Section 5 of is used. Where an AMP session has already been established as a result of such an advertisement, the receiving router SHOULD tear the session down. When a router receives a usable AMP Measurement Group sub-TLV, it MUST determine whether it has an IP endpoint configured as a member of the AMG identified by the Group ID, and whether the advertised endpoint address is of that AMG's address family. If either is not the case, the sub-TLV MUST be ignored. Otherwise, if no AMP session for that AMG has already been established between the two IP endpoints, the receiving router attempts to establish one. When both IP endpoints attempt to establish a session for the same AMG, the session initiated by the endpoint with the greater IP address takes precedence, where the two addresses are compared as unsigned octet strings. Since both endpoints belong to the same AMG, they are of the same address family and the comparison is therefore always between addresses of equal length. Because the AMP Measurement Group sub-TLV is advertised in a Router CAPABILITY TLV with the S flag set, it is flooded across the entire routing domain and is leaked between levels by L1/L2 routers as specified in . This satisfies the requirement for discovery of measurement group members that are not in the same IS-IS level as the advertising router. As noted in Section 4 of , at least one L1/L2 router in every area of the domain must support the Router CAPABILITY TLV for domain-wide flooding of TLVs originated by L1 routers to work. Correspondingly, the AMP Measurement Group TLV is advertised in an AS-scoped OSPF RI LSA and is therefore flooded throughout the OSPF routing domain. This satisfies the requirement for discovery of measurement group members that are not in the same OSPF area as the advertising router. See for the flooding scope rules, including the additional area-scoped advertisement required for stub areas and NSSAs. If a router's measurement group membership changes, it MUST update its Router CAPABILITY TLV or RI LSA advertisement accordingly. An OSPF router that no longer participates in any AMG MUST originate a new RI LSA that no longer includes any AMP Measurement Group TLV; if no other TLVs remain in the LSA, it MUST either advertise an empty RI LSA or purge the LSA by prematurely aging it. Routers receiving updated information MUST process the changes and update their record of measurement group membership.

Inter-IGP Domain Discovery of Active Measurement Groups With networks being divided into multiple IGP domains for scaling and operational reasons, the IP endpoints that are members of a common AMG often span IGP domains. BGP-LS enables the collection and distribution of IGP link-state topology information via BGP sessions across IGP areas/levels and domains. The AMG membership of a node can thus be distributed along with the topology information across IGP domains and even across multiple Autonomous Systems (ASes) within a single administrative domain, as has been done for Segment Routing and for S-BFD discriminators . BGP-LS specifies the Node Network Layer Reachability Information (NLRI) for the advertisement of nodes and their attributes using the BGP-LS Attribute. The AMG memberships of a node are considered a node-level attribute and are advertised as such. This document defines a new BGP-LS Attribute TLV, the AMP Measurement Group TLV, with the following format:

BGP-LS AMP Measurement Group TLV Format

Fields:

Type:

2 octets. TBD3 (to be assigned by IANA, see )

Length:

2 octets. The length of the value field in octets. The address family is inferred from the length of the TLV. The length MUST be 8 when an IPv4 endpoint address is carried and 20 when an IPv6 endpoint address is carried. A TLV with any other length is malformed and is handled as specified for the BGP-LS Attribute in .

Group ID:

2 octets. The Group ID of the AMG in which the node's endpoint participates, as advertised by the originating node in the underlying IGP. The semantics, reserved values, and range of the Group ID are as specified in .

Reserved:

2 octets. This field MUST be set to zero on transmission and MUST be ignored on receipt.

IPv4/IPv6 Endpoint Address:

4 octets for IPv4 or 16 octets for IPv6. The IP endpoint through which the node participates in the AMG identified by the Group ID.

The AMP Measurement Group TLV can be added to the BGP-LS Attribute associated with the Node NLRI that originates the corresponding underlying IGP sub-TLV or TLV. This information is derived from the protocol-specific advertisements as follows:

• IS-IS, as defined by the AMP Measurement Group sub-TLV in of this document.
• OSPFv2/OSPFv3, as defined by the AMP Measurement Group TLV in of this document.

A node may participate in multiple AMGs and may use multiple IP endpoints. Consequently, the BGP-LS Attribute associated with a Node NLRI MAY include more than one AMP Measurement Group TLV: one for each combination of Group ID and IP endpoint advertised by that node in the underlying IGP. The set of AMP Measurement Group TLVs associated with a Node NLRI reflects the set of AMG memberships advertised by that node. The AMP and any non-default AMP parameters associated with an AMG are not carried in the BGP-LS Attribute TLV, consistent with the IGP advertisements from which it is derived. As specified in , Group IDs are configured consistently within a single administrative domain; where BGP-LS is used for inter-IGP domain discovery, that administrative domain encompasses all of the IGP domains from which the AMG membership information is collected. The protocol extensions introduced in this section augment the existing IGP topology information that is distributed via BGP-LS . The procedures and protocol extensions defined in this document do not affect BGP protocol operations and management other than as discussed in the Manageability Considerations of . Specifically, the malformed NLRI attribute tests in the Fault Management considerations of now encompass the new TLV defined in this section.

IANA Considerations

IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV IANA is requested to assign a new sub-TLV type from the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry in the "IS-IS TLV Codepoints" registry group for the AMP Measurement Group sub-TLV defined in of this document. The registration procedure for this registry is Expert Review ; guidance for the IESG-designated experts is provided in . The requested value is from the unassigned range 31-160. AMP Measurement Group Sub-TLV Registration

Value	Description	MP	Reference
TBD1	AMP Measurement Group	y	This document

The MP column is set to "y" since the AMP Measurement Group sub-TLVs advertised by a router may be distributed across multiple instances of the IS-IS Router CAPABILITY TLV as specified in and of this document. Early allocation of this codepoint in accordance with is requested. [RFC Editor: please replace TBD1 with the value assigned by IANA, both in and in , and remove this note.]

OSPF Router Information (RI) TLVs IANA is requested to assign a new TLV type from the "OSPF Router Information (RI) TLVs" registry in the "Open Shortest Path First (OSPF) Parameters" registry group for the AMP Measurement Group TLV defined in of this document. The registration procedure for the 1-32767 range of this registry is IETF Review , as specified in Section 5.3 of . The requested value is from the unassigned portion of that range. AMP Measurement Group TLV Registration

Value	TLV Name	Reference
TBD2	AMP Measurement Group	This document

Early allocation of this codepoint in accordance with is requested. [RFC Editor: please replace TBD2 with the value assigned by IANA, both in and in , and remove this note.]

BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs IANA is requested to allocate a new code point from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry in the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group for the AMP Measurement Group TLV defined in of this document. The column "IS-IS TLV/Sub-TLV" defined in the registry does not require any value and should be left empty. BGP-LS AMP Measurement Group TLV Code Point Allocation

TLV Code Point	Description	Reference
TBD3	AMP Measurement Group	This document

Early allocation of this codepoint in accordance with is requested. [RFC Editor: please replace TBD3 with the value assigned by IANA, both in and in , and remove this note.]

Security Considerations This document defines mechanisms for advertising measurement group membership in IS-IS and OSPF. The security considerations for IS-IS as specified in and apply, as do the security considerations for OSPFv2 , OSPFv3 , the OSPF Opaque LSA option , and the OSPF RI LSA . An attacker that can inject false AMP Measurement Group sub-TLVs or TLVs could cause routers to attempt to establish measurement sessions with incorrect endpoints, potentially leading to:

• Failed measurement sessions
• Misconfiguration of measurement infrastructure
• Resource exhaustion if many false endpoints are advertised
• Measurement traffic directed at a third party, if an attacker advertises an address belonging to a victim as an endpoint of a widely deployed AMG

To mitigate these risks, and as recommended in Section 5 of for information carried in the Router CAPABILITY TLV, an integrity mechanism such as those specified in or SHOULD be applied to IS-IS protocol exchanges. Correspondingly, an authentication mechanism such as those specified in for OSPFv2 or in or for OSPFv3 SHOULD be applied to OSPF protocol exchanges. Additionally, operators SHOULD configure appropriate access controls and monitoring to detect and prevent unauthorized advertisements. The information advertised in the AMP Measurement Group sub-TLV and TLV reveals which routers are participating in measurement groups and which interface addresses are used for measurement purposes. This information may be considered sensitive in some deployments. Since the IS-IS sub-TLV is advertised with the S flag set and the OSPF TLV is advertised in an AS-scoped RI LSA, this information is flooded throughout the routing domain rather than being confined to the level or area in which it originates, which widens the set of routers to which it is disclosed. Operators should consider the implications of this information disclosure when deploying this mechanism. The BGP-LS extension defined in augments the existing IGP topology information that can be distributed via BGP-LS . It does not affect the BGP security model other than as discussed in the Security Considerations of , i.e., the aspects related to limiting the nodes and consumers with which the topology information is shared via BGP-LS to trusted entities within an administrative domain. The IGP instances originating this information are assumed to support the security and authentication mechanisms described above. Additionally, since this information identifies the IP endpoints used for active measurement, distributing it via BGP-LS widens the scope of the information disclosure discussed in the preceding paragraph beyond a single IGP domain, and makes it possible for an attacker with access to the BGP-LS information to attempt to establish AMP sessions with the advertised endpoints.

References Normative References International Organization for Standardization Informative References

Acknowledgements Thanks to Rakesh Gandhi for discussion of requirements.