draft-ietf-ccamp-inter-domain-framework-05.txt | draft-ietf-ccamp-inter-domain-framework-06.txt | |||
---|---|---|---|---|
Network Working Group Adrian Farrel | Network Working Group Adrian Farrel | |||
IETF Internet Draft Old Dog Consulting | IETF Internet Draft Old Dog Consulting | |||
Proposed Status: Informational | Proposed Status: Informational | |||
Expires: January 2007 Jean-Philippe Vasseur | Expires: February 2007 Jean-Philippe Vasseur | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
Arthi Ayyangar | Arthi Ayyangar | |||
Nuova Systems | Nuova Systems | |||
August 2006 | ||||
A Framework for Inter-Domain Multiprotocol Label Switching | A Framework for Inter-Domain Multiprotocol Label Switching | |||
Traffic Engineering | Traffic Engineering | |||
draft-ietf-ccamp-inter-domain-framework-05.txt | draft-ietf-ccamp-inter-domain-framework-06.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at line 822 | skipping to change at line 825 | |||
security procedures for existing protocols in the MPLS context | security procedures for existing protocols in the MPLS context | |||
continue to apply for the intra-domain cases. | continue to apply for the intra-domain cases. | |||
Inter-domain security may be considered as a more important and more | Inter-domain security may be considered as a more important and more | |||
sensitive issue than intra-domain security since in inter-domain | sensitive issue than intra-domain security since in inter-domain | |||
traffic engineering control and information may be passed across | traffic engineering control and information may be passed across | |||
administrative boundaries. The most obvious, and most sensitive case | administrative boundaries. The most obvious, and most sensitive case | |||
is inter-AS TE. | is inter-AS TE. | |||
All of the intra-domain security measures for the signaling and | All of the intra-domain security measures for the signaling and | |||
routing protocols are equally applicable and efficacious in the | routing protocols are equally applicable in the inter-domain case. | |||
inter-domain case, and it may be reasonably assumed that if the | There is, however, a greater likelihood of them being applied in the | |||
measures are strong enough for intra-domain security then they are | inter-domain case. | |||
also strong enough for inter-domain security. There is, however, a | ||||
greater likelihood of them being applied in the inter-domain case. | Security for inter-domain MPLS TE is the subject of a separate | |||
document that analyses the security deployment models and risks. This | ||||
separate document must be completed before inter-domain MPLS TE | ||||
solution documents can be advanced. | ||||
Similarly, the PCE procedures [PCE] are subject to security measures | Similarly, the PCE procedures [PCE] are subject to security measures | |||
for the exchange computation information between PCEs, and for LSRs | for the exchange computation information between PCEs, and for LSRs | |||
that request path computations from a PCE. The requirements for this | that request path computations from a PCE. The requirements for this | |||
security (set out in [PCE-REQ]) apply whether the LSR and PCE (or the | security (set out in [PCE-REQ]) apply whether the LSR and PCE (or the | |||
cooperating PCEs) are in the same domain or lie across domain | cooperating PCEs) are in the same domain or lie across domain | |||
boundaries. | boundaries. | |||
It should be noted, however, that techniques used for (for example) | It should be noted, however, that techniques used for (for example) | |||
authentication require coordination of secrets, keys, or passwords | authentication require coordination of secrets, keys, or passwords | |||
End of changes. 4 change blocks. | ||||
7 lines changed or deleted | 13 lines changed or added | |||
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |