idnits 2.17.1 draft-shore-afwc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1191. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1198. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1204. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 161: '... services MUST be provided by the cr...' RFC 2119 keyword, line 173: '... the lower layer MUST establish the au...' RFC 2119 keyword, line 185: '... SHOULD be distinct. The receiver o...' RFC 2119 keyword, line 243: '... An initiator MAY request a pinhole ...' RFC 2119 keyword, line 246: '... MUST NOT be construed to indicate t...' (40 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 7, 2006) is 6439 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '14' on line 742 looks like a reference -- Missing reference section? 'ETH' on line 1018 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Shore 3 Internet-Draft D. McGrew 4 Expires: March 11, 2007 Cisco Systems 5 September 7, 2006 7 An Authorized IP Firewall Control Application 8 draft-shore-afwc-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 11, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 The Authorized Firewall Control Protocol provides an interface that 42 allows network entities to request firewall and NAT services and 43 resources. It is an instance of a protocol that provides 44 authorizations and other security servcies, and interworks with other 45 such instances. AFWC uses its authorization facilities to provide 46 network administrators more control over network border admissions 47 decisions than is provided by other firewall pinholing protocols. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Network scenarios . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4. Pinholes . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 4.1. Firewall pinholes . . . . . . . . . . . . . . . . . . . . 8 56 4.2. NAT Table mappings . . . . . . . . . . . . . . . . . . . . 8 57 5. Access Type . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 6. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . 10 59 6.1. Open Pinhole Exchange . . . . . . . . . . . . . . . . . . 10 60 6.1.1. Start message . . . . . . . . . . . . . . . . . . . . 10 61 6.1.2. Offer Message . . . . . . . . . . . . . . . . . . . . 10 62 6.1.3. Request message . . . . . . . . . . . . . . . . . . . 11 63 6.1.4. Response message . . . . . . . . . . . . . . . . . . . 12 64 6.2. Close Pinhole Exchange . . . . . . . . . . . . . . . . . . 13 65 7. Data formats . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 7.1. IPV4_SELECTOR . . . . . . . . . . . . . . . . . . . . . . 15 67 7.2. IPV6_SELECTOR . . . . . . . . . . . . . . . . . . . . . . 16 68 7.3. NAT_TUPLE . . . . . . . . . . . . . . . . . . . . . . . . 16 69 7.4. INFO . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 7.5. NAT_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 7.6. ICMP_MESSAGE . . . . . . . . . . . . . . . . . . . . . . . 19 72 7.7. PINHOLE_ID . . . . . . . . . . . . . . . . . . . . . . . . 20 73 7.8. APPLICATION_ID . . . . . . . . . . . . . . . . . . . . . . 21 74 8. Traffic Flows . . . . . . . . . . . . . . . . . . . . . . . . 23 75 9. Responder Discovery . . . . . . . . . . . . . . . . . . . . . 24 76 10. Authorizations . . . . . . . . . . . . . . . . . . . . . . . . 25 77 11. NAT discussion . . . . . . . . . . . . . . . . . . . . . . . . 27 78 11.1. Stand-alone NAT . . . . . . . . . . . . . . . . . . . . . 27 79 11.2. The NAT is co-resident with the firewall . . . . . . . . . 27 80 11.3. There is a NAT between the controller and the firewall . . 28 81 12. NAT call flow examples . . . . . . . . . . . . . . . . . . . . 29 82 12.1. Calling endpoint is NATted, controls firewall . . . . . . 29 83 12.2. Calling endpoint is NATted, CCS controls firewall . . . . 30 84 12.3. Called endpoint NATted . . . . . . . . . . . . . . . . . . 31 85 13. Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 86 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 89 Intellectual Property and Copyright Statements . . . . . . . . . . 37 91 1. Introduction 93 This specification defines a protocol for establishing and managing 94 firewall pinholes, and a formal model for evaluating pinhole requests 95 against a pre-established set of authorizations. The design relies 96 on a lower layer in the system to provide cryptographic protections, 97 and to provide the authorizations of the other endpoint. 99 In this document we refer to a "firewall control application." The 100 application actually supports requests to both firewalls and NATs, 101 and while we do not consider NAT to be a type of firewall or to be a 102 security device in general, we recognize that there are substantial 103 semantic, topological, and protocol similarities between asking for a 104 firewall pinhole and asking for a NAT table mapping. For the sake of 105 convenience we will refer to a firewall control application 106 throughout this document, acknowledging that in reality the 107 application includes NAT, a non-firewall function. 109 2. Network scenarios 111 Participants in an AFWC dialogue include an initiator, a responder, 112 and an authenticationserver. In the firewall control application, 113 the "initiator" is the entity requesting a firewall pinhole or 114 service, or NAT table mapping. This might be, for example, an IP 115 telephony call control server, or a network gaming endpoint. The 116 "responder" is the firewall or NAT, and the authentication server is 117 the server providing authentication and authorization services to the 118 initiator and responder. 120 In this document we will use "initiator" and "responder" to describe 121 protocol participants. 123 Firewall control is typically seen as between elements in the same 124 network, allowing implicit authorization based on topological 125 considerations such as sharing of address space. For example, 127 ______________ _____________ 128 / \ / \ 129 / Local \ / Public \ 130 | network ------ internet | 131 | _| FW | | 132 | __--- ------ | 133 \ CCS---- / \ / 134 \______________/ \_____________/ 136 In this figure, a VoIP call control server ("CCS") establishes a 137 request connection to a firewall ("FW"). 139 However, it may be the case in some instances or for some 140 applications that an external entity, outside of the local network or 141 address space, may wish to request pinholes or other resources from 142 the firewall. 144 ______________ _____________ 145 / \ / \ 146 / Local \ / Public \ 147 | network ------ internet | 148 | | FW |-_ | 149 | ------ -__ | 150 \ / \ -- CCS / 151 \______________/ \_____________/ 153 In this scenario the trust relationships will need to be made 154 explicit, and there may be substantial changes to the security 155 considerations. 157 3. Transport 159 AFWC relies on a cryptographic layer for transport and to provide 160 authorizations of the other endpoint. The following cryptographic 161 services MUST be provided by the crypto layer: 163 o entity authentication of the peer 165 o confidentiality of all messages sent to and from the peer 167 o message authentication on all messages sent to and from the peer 169 o protection from replayed messages 171 o protection from reflected messages. 173 In addition, the lower layer MUST establish the authorizations of the 174 peer in a secure and reliable manner and pass these authorizations to 175 this protocol. 177 The messages are framed using the following format. The REQUEST 178 (Figure 3) and RESPONSE (Figure 4) elements convey arbitrary data in 179 their Body fields. This data is meant to convey a request or a 180 response. The Access Type Identifier (ATI) field (Section 5) 181 indicates the type of access that is being requested. The Body field 182 is interpreted according to the value of the ATI field. The Request 183 Identifier field is used to match replies to requests. That field 184 can be set to any value by the sender of a REQUEST; these values 185 SHOULD be distinct. The receiver of a REQUEST element MUST set that 186 field of the corresponding RESPONSE element to the same value. 188 0 1 2 3 189 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |M|R| Typecode = REQUEST | Length | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Request Identifier | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Access Type Identifier | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | 198 ~ Body ~ 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 3 203 0 1 2 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |M|R| Typecode = RESPONSE | Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Request Identifier | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Access Type Identifier | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | | 213 ~ Body ~ 214 | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 4 219 4. Pinholes 221 4.1. Firewall pinholes 223 In this specification, a pinhole is a traffic flow that the firewall 224 permits, which can be very narrowly scoped. For example, a pinhole 225 can be created that allows VoIP traffic to flow between a phone 226 behind the firewall and a phone outside the firewall, but which does 227 not allow traffic from any other hosts outside the firewall to reach 228 the phone behind the firewall. The definition of a traffic flow used 229 in this specification appears below. 231 Each pinhole is associated with a PINHOLE_ID value, which can be used 232 to uniquely identify the pinhole, and a timer value that indicates 233 when the pinhole is to expire. 235 A pinhole corresponds to a "permit" statement, in that it only allows 236 traffic through the firewall, and cannot cause traffic to be blocked. 237 There is no equivalent "deny" statement in this specification. This 238 design decision makes the application simpler and should make 239 implementations easier to manage. (n.b. this should not in any way be 240 construed as suggesting that an application cannot request the 241 closure of a pinhole it created -- see below) 243 An initiator MAY request a pinhole for which the traffic flow is 244 already allowed through the responder (firewall), either in part or 245 in whole. In this case, if the responder rejects the request, it 246 MUST NOT be construed to indicate that the flow has been blocked. 248 4.2. NAT Table mappings 250 A NAT table mapping is the data structure in a NAT providing the 251 mapping between an external {address, port, protocol} tuple and an 252 internal, private {address, port, protocol} tuple. In some types of 253 NAT there may be additional data associated with the mapping. For 254 example, in a symmetric NAT each mapping is also associated with one 255 external peer. Those additional data are opaque to the endpoint and 256 are internal to the NAT. 258 A NAT table mapping is represented by a PINHOLE_ID value, as well. 260 5. Access Type 262 The IP Firewall Control application is identified by an Access Type 263 Code of ACCESS_TYPE_FW_CTL. The cryptographic and authorization 264 layers use this code in order to deliver the IP Firewall Control 265 messages to the appropriate application on each participating device. 266 The Access Type Code identifies an authorization application in the 267 same way that a well-known TCP port identifies a service on a host. 269 6. Message Exchanges 271 This section defines the IP Firewall application protocol. We use 272 the notation that T* denotes zero or more instances of the term T, T+ 273 denotes one or more instances of the term T, and T? denotes zero or 274 one instances of the term T. In this section, I is the initiator, a 275 device that is making an access control request to the firewall, and 276 R is the responder, which is the firewall itself. 'I' refers to the 277 initiator (the entity requesting pinholes) and 'R' refers to the 278 responder, which in this case is the firewall. 280 The crypto layer and transport layer operate below the application 281 layer, and provide the essential security services and reliable data 282 transport. The application layer contains the "access control 283 dialog". It contains four messages: Start, Offer, Request, and 284 Response. These messages are described below along with the data 285 formats and the semantics used in the IP Firewall Control 286 application. 288 6.1. Open Pinhole Exchange 290 An initiator begins an Open Pinhole exchange in order to cause a 291 responder to allow a particular traffic flow. The flow is described 292 by one or more IPV4_SELECTOR or IPV6_SELECTOR TLVs, and is associated 293 with a particular PINHOLE_ID. 295 +----------+--------+-----------------------------------------------+ 296 | Message | Flow | Format | 297 +----------+--------+-----------------------------------------------+ 298 | Start | I -> R | | 299 | | | | 300 | Offer | R -> I | (PINHOLE_ID (IPV4_SELECTOR | IPV6_SELECTOR)* | 301 | | | ) | INFO | 302 | | | | 303 | Request | I -> R | PINHOLE_ID (IPV4_SELECTOR | IPV6_SELECTOR)? | | 304 | | | NAT_TUPLE? | INFO | 305 | | | | 306 | Response | R -> I | PINHOLE_ID INFO? | NAT_INFO? | 307 +----------+--------+-----------------------------------------------+ 309 6.1.1. Start message 311 The Start message is sent by the initiator to the responder to 312 initiate the authorization exchange. The message body is empty. 314 6.1.2. Offer Message 316 A responder constructs the Offer message as follows. First, it MUST 317 check the authorizations of the initiator to make sure that it is 318 authorized to act as a controller (see the section on 319 Authorizations). If it is not, then the Offer message MUST contain 320 an INFO element with Status Code ERROR and Info Code 321 ACCESS_NOT_ALLOWED, and the session must be terminated. Otherwise, 322 the responder encodes into the Offer a PINHOLE_ID that is not 323 currently in use, which will be associated with the pinhole created 324 by the session, if it completes successfully. The responder MAY send 325 one or more IPV4_SELECTOR or IPV6_SELECTOR TLV element(s) describing 326 the traffic that it is willing to allow. The use of these elements 327 provides basic capability discovery and topology discovery . The 328 responder indicates to the authorization system the maximum time, 329 expressed as a number of seconds, that it is willing to allow a 330 pinhole to remain open. This value is used by the authorization 331 system, and is also conveyed to the initiator. 333 A responder that also does NAT, or a stand-alone NAT, MUST include an 334 INFO element that has a Status Code of CAPABILITIES with the NAT flag 335 set. 337 The responder MAY include INFO elements that indicate other 338 conditions, though the controller MAY ignore them. 340 An initiator processes an Offer message as follows. First, it MUST 341 check the authorizations of the responder to make sure that it is 342 authorized to act as a firewall or NAT (see the section on 343 Authorizations). If it is not, then the Offer message MUST contain 344 an INFO element with Status Code ERROR and Info Code 345 ACCESS_NOT_ALLOWED, and the session must be terminated. If any 346 IPV4_SELECTOR or IPV6_SELECTOR element(s) appear in the message, the 347 initiator SHOULD use the information to guide the construction of the 348 Request. 350 6.1.3. Request message 352 The initiator builds the firewall request by including the PINHOLE_ID 353 element sent in the Offer and zero or more IPV4_SELECTOR or 354 IPV6_SELECTOR elements that describe the traffic that the initiator 355 is requesting to be allowed to traverse the firewall. The initiator 356 indicates to the authorization system the minimum time that it would 357 like for the pinhole to remain open; this value MUST be no greater 358 than the duration indicated with the Offer message. The initiator 359 MAY include INFO elements that indicate other conditions, though the 360 responder MAY ignore them. 362 The initiator builds the NAT request by including the PINHOLE_ID 363 element sent in the Offer and one or more NAT_TUPLE elements that 364 describe the internal address for which the initiator is requesting a 365 mapping. The presence of a NAT_TUPLE element implies that a NAT 366 table mapping is being requested, and, by implication, that a 367 firewall pinhole request is being requested. There may be cases in 368 which there are no SELECTOR elements but one or more NAT_TUPLE 369 elements; in that case the request will be treated as being for both 370 a NAT table mapping and a firewall pinhole for each NAT_TUPLE 371 element. Otherwise the construction of the request message is the 372 same as it is for a firewall pinhole request. 374 A responder processes a Request message as follows. First, it MUST 375 check the authorizations of the initiator to make sure that it is 376 authorized to open the pinhole that it has requested (see the section 377 on Authorizations). If it is not, then the Offer message MUST 378 contain an INFO element with Status Code ERROR and Info Code 379 ACCESS_NOT_ALLOWED, and the session must be terminated. Otherwise, 380 the responder constructs a Response message. This message serves as 381 an acknowledgement. 383 NAT processing of the Request message is the same as firewall 384 processing of the Request message. 386 6.1.4. Response message 388 The Response message contains the PINHOLE_ID that was included in the 389 Offer and the Request. In the firewall case, if nothing goes wrong, 390 then this message contains an INFO element with a Status Code of 391 NOTIFY and an Info Code of OK. If there are any errors or warnings, 392 then the INFO element must be set appropriately. If the duration 393 requested by the initiator is greater than the maximum that the 394 responder is willing to allow, then the responder SHOULD install the 395 pinhole with the maximum duration to which it consents. In this 396 case, the firewall SHOULD send an INFO element with Status Code 397 WARNING and Info Code of DURATION_TOO_LONG. The responder MUST 398 implement the pinhole before sending the Response. The number of 399 seconds before the pinhole expires is provided to the authorization 400 system, which forwards it to the controller. 402 If the request was for a NAT table mapping, the Response message MUST 403 also contain a NAT_INFO TLV. The NAT_INFO TLV is used to communicate 404 the external address back to the controller. 406 An initiator processes a Response as follows. It uses the PINHOLE_ID 407 to associate the reply with the request that it made earlier. If an 408 INFO element with Status Code NOTIFY and Info Code OK appears in the 409 message, and no element with Status Code ERROR appears in the 410 message, then the session has concluded successfully. Otherwise, the 411 controller MUST NOT assume that the pinhole that it has requested has 412 been implemented by the responder. If an INFO element containing 413 DURATION_TOO_LONG appears, then the initiator SHOULD be prepared to 414 make another Open Pinhole request before the pinhole times out and is 415 removed by the responder. The duration conveyed by the authorization 416 system indicates the number of seconds that the responder has 417 committed to keep the pinhole open. 419 6.2. Close Pinhole Exchange 421 An initiator initiates a Close Pinhole exchange to close a responder 422 to a traffic flow that had been previously allowed via an Open 423 Pinhole exchange. A Close Pinhole exchange causes the responder to 424 reverse the firewall policy changes that were made in the previous 425 exchange. The messages for this exchange are outlined in the 426 following table. 428 +----------+--------+-----------------------------------------------+ 429 | Message | Flow | Format | 430 +----------+--------+-----------------------------------------------+ 431 | Start | I -> R | | 432 | | | | 433 | Offer | R -> I | (PINHOLE_ID (IPV4_SELECTOR | IPV6_SELECTOR)* | 434 | | | ) | INFO | 435 | | | | 436 | Request | I -> R | CLOSE_PINHOLE PINHOLE_ID+ | 437 | | | | 438 | Response | R -> I | CLOSE_PINHOLE (PINHOLE_ID | INFO)+ | 439 +----------+--------+-----------------------------------------------+ 441 The Start message is empty, as in the Open Pinhole exchange. 443 The responder constructs the Offer exactly as done for the Open 444 Pinhole exchange (as it must, since at this point in the protocol it 445 has no idea whether or not the initiator will be requesting to open 446 or close a pinhole). 448 The initiator constructs the Request as follows. The PINHOLE_ID sent 449 by the responder is ignored. The message MUST start with a 450 CLOSE_PINHOLE TLV, which indicates that the initiator is requesting 451 that one or more previously created pinholes are to be closed. The 452 PINHOLE_ID element associated with the pinhole(s) that the initiator 453 wishes to close are included in the message. At least one PINHOLE_ID 454 element MUST appear in the message. 456 The responder constructs the Reply as follows. The message MUST 457 start with a CLOSE_PINHOLE TLV, which acknowledges that the exchange 458 will close previously opened pinholes. For each PINHOLE_ID that 459 appears in the Request, the responder includes a PINHOLE_ID in the 460 Response, followed by a INFO TLV element. The INFO element contains 461 a Status Code of NOTIFY and an Info Code of OK if the pinhole was 462 closed successfully. 464 The Close Pinhole Exchange is the same for NATs as it is for 465 firewalls. 467 7. Data formats 469 The IP Firewall application defines the following TLV types: 471 7.1. IPV4_SELECTOR 473 IPV4_SELECTOR encodes a traffic selector, which defines a particular 474 IP Version Four packet flow. The firewall uses these values as the 475 basis for packet matches. The Value field of an IPV4_SELECTOR TLV 476 element consists of the ipv4_selector_t structure shown below, in 477 network byte order: 479 typedef struct { 480 uint32_t src_addr; 481 uint32_t src_mask; 482 uint32_t dst_addr; 483 uint32_t dst_mask; 484 uint16_t src_port_lo; 485 uint16_t src_port_hi; 486 uint16_t dst_port_lo; 487 uint16_t dst_port_hi; 488 uint16_t protocol; 489 uint32_t spi; 490 uint16_t reserved; 491 } ipv4_selector_t; 493 with the fields as follows: 495 src_addr: source address in the IP header 497 src_mask: a value to mask with the src_addr field 499 dst_addr: destination address in the IP header 501 dst_mask: a value to mask with the dst_addr field 503 src_port_lo: ports may be specified as a range of values; this is 504 the low value for the source port in the IP header 506 src_port_hi: high value for the range of source ports in the IP 507 header 509 dst_port_lo: low value for the range of destination ports in the IP 510 header 512 dst_port_hi: high value for the range of destination ports in the IP 513 header 515 protocol: the protocol number carried in the IP header 517 spi: IPSec SPI. 519 The value 0x00 is used in the protocol field to denote a match to any 520 protocol. 522 7.2. IPV6_SELECTOR 524 IPV6_SELECTOR encodes a traffic selector, which defines a particular 525 IP Version Six packet flow. The Value field of an IPV6_SELECTOR TLV 526 element consists of the ipv6_selector_t structure shown below, in 527 network byte order: 529 typedef struct { 530 uint128_t src_addr; 531 uint128_t src_mask; 532 uint128_t dst_addr; 533 uint128_t dst_mask; 534 uint32_t flow_label; 535 uint16_t src_port_lo; 536 uint16_t src_port_hi; 537 uint16_t dst_port_lo; 538 uint16_t dst_port_hi; 539 uint16_t protocol; 540 uint16_t reserved; 541 } ipv6_selector_t; 543 with the fields as described above. 545 7.3. NAT_TUPLE 547 The NAT_TUPLE TLV contains the description of an {address, port, 548 protocol} tuple for which a NAT table mapping is being requested. In 549 other words, the NAT_TUPLE describes an internal address. 551 typedef struct { 552 uint32_t addr; 553 uint16_t port; 554 uint16_t protocol; 555 uint32_t hint_addr; 556 uint16_t hint_port; 557 uint16_t hint_protocol; 559 } nat_tuple_t; 561 The addr field represents an IPv4 address. Because this is for NAT, 562 we assume that we will not need to support NAT functions for IPv6, 563 although this may be revisited if necessary. 565 When the initiator is making the request on behalf of another party 566 (for example, a call control server requesting a media pinhole for a 567 VoIP endpoint) the hint_addr, hint_port, and hint_protocol fields 568 SHOULD be used to assist a NAT device in resolving ambiguous 569 requests. An example of ambiguity would be those cases when the 570 NATted address spaces attached to two different interfaces on the 571 same NAT use the same or overlapping addresses. 573 An example of its use would be for, say, a VoIP call control server 574 to use the hint fields to send the {address, port, protocol} tuple of 575 the endpoint from which it received signaling to the NAT. The NAT 576 would search its mapping tables on all interfaces for a match. If a 577 match is found the interface with which the matching mapping is 578 associated would be the interface to which the request is applied. 580 If the hint fields are not used they MUST be null. 582 7.4. INFO 584 typedef struct { 585 uint32_t status_code; 586 uint32_t info_code; 587 } info_t; 589 The Status Code describes the status state machine of the sender of 590 the INFO element. If any condition occurred that will prevent the 591 successful completion of the exchange, then this field will have the 592 value ERROR. This value indicates to the recipient that it MUST NOT 593 expect the sender to participate in the exchange any further. 595 The Status Codes are: 597 +--------------+--------------------------------------------------+ 598 | Message | Meaning | 599 +--------------+--------------------------------------------------+ 600 | OKAY | No error, no message | 601 | | | 602 | ERROR | An error was encountered | 603 | | | 604 | CAPABILITIES | This element contains a capabilities description | 605 +--------------+--------------------------------------------------+ 607 The Info Code provides detailed information, but does not convey any 608 information about the base authorization exchange. 610 The Info Code values that can be used by the IP Firewall Control 611 application are as follows: 613 +------------------------+------------------------------------------+ 614 | Value | Meaning | 615 +------------------------+------------------------------------------+ 616 | OK | No problems occurred | 617 | | | 618 | ACCESS_NOT_ALLOWED | Access is denied due to lack of | 619 | | authorization | 620 | | | 621 | DURATION_TOO_LONG | Duration requested is too long | 622 | | | 623 | BAD_PARAMETER | A bad parameter appeared in a request | 624 | | | 625 | TRY_AGAIN | Request cannot be completed, but try | 626 | | again | 627 | | | 628 | RESOURCE_NOT_AVAILABLE | A resource needed for the request is not | 629 | | available | 630 | | | 631 | NAT | This device provides NAT functions | 632 +------------------------+------------------------------------------+ 634 7.5. NAT_INFO 636 The NAT_INFO TLV carries the response to the NAT request (implicit in 637 the inclusion of a NAT_TUPLE TLV in the Request message). It 638 includes both the internal and external addresses. 640 typedef struct { 641 uint32_t i_addr; 642 uint32_t e_addr; 643 uint32_t i_port; 644 uint32_t e_port; 645 uint16_t protocol; 646 } nat_info_t; 648 where the fields are as follows: 650 i_addr: Internal IPv4 address 652 e_addr: External IPv4 address 654 i_port: Internal port 656 e_port: External port 658 protocol Protocol (TCP, UDP, SCTP, etc.) 660 7.6. ICMP_MESSAGE 662 typedef struct { 663 u_char icmp_type; 664 u_char icmp_code; 665 } icmp_t; 667 ICMP_MESSAGE carries a description of a filter rule for ICMP 668 messages, based on ICMP message types and codes. 670 The values are as follows: 672 ICMP_ECHOREPLY 0 673 ICMP_UNREACH 3 674 ICMP_UNREACH_NET 0 675 ICMP_UNREACH_HOST 1 676 ICMP_UNREACH_PROTOCOL 2 677 ICMP_UNREACH_PORT 3 678 ICMP_UNREACH_NEEDFRAG 4 679 ICMP_UNREACH_SRCFAIL 5 680 ICMP_UNREACH_NET_UNKNOWN 6 681 ICMP_UNREACH_HOST_UNKNOWN 7 682 ICMP_UNREACH_ISOLATED 8 683 ICMP_UNREACH_NET_PROHIB 9 684 ICMP_UNREACH_HOST_PROHIB 10 685 ICMP_UNREACH_TOSNET 11 686 ICMP_UNREACH_TOSHOST 12 687 ICMP_UNREACH_FILTER_PROHIB 13 688 ICMP_UNREACH_HOST_PRECEDENCE 14 689 ICMP_UNREACH_PRECEDENCE_CUTOFF 15 690 ICMP_SOURCEQUENCH 4 691 ICMP_REDIRECT 5 692 ICMP_REDIRECT_NET 0 693 ICMP_REDIRECT_HOST 1 694 ICMP_REDIRECT_TOSNET 2 695 ICMP_REDIRECT_TOSHOST 3 696 ICMP_ECHO 8 697 ICMP_ROUTERADVERT 9 698 ICMP_ROUTERSOLICIT 10 699 ICMP_TIMXCEED 11 700 ICMP_TIMXCEED_INTRANS 0 701 ICMP_TIMXCEED_REASS 1 702 ICMP_PARAMPROB 12 703 ICMP_PARAMPROB_ERRATPTR 0 704 ICMP_PARAMPROB_OPTABSENT 1 705 ICMP_PARAMPROB_LENGTH 2 706 ICMP_TSTAMP 13 707 ICMP_TSTAMPREPLY 14 708 ICMP_IREQ 15 709 ICMP_IREQREPLY 16 710 ICMP_MASKREQ 17 711 ICMP_MASKREPLY 18 713 7.7. PINHOLE_ID 715 typedef struct { 716 uint32_t id; 717 uint32_t context; 719 } pinhole_id_t; 721 The PINHOLE_ID is an identifier generated by the responder and 722 associated with a particular pinhole. The id field of a PINHOLE_ID 723 TLV is 32 bits long, and MAY be treated as an unsigned integer in 724 network byte order (e.g. for display to the user). The method by 725 which the firewall generates these identifiers is intentionally left 726 unspecified, in order to provide maximum flexibility for 727 implementations. Of course, each PINHOLE_ID value associated with an 728 existing pinhole MUST be unique. Each PINHOLE_ID offered to a 729 controller in an Offer message SHOULD be unique, though it is 730 acceptable for a controller to offer the same value twice as long as 731 it detects this condition and does not attempt to install multiple 732 pinholes with the same PINHOLE_ID values. 734 The context field carries responder-specific information to 735 distinguish context. Examples of contexts include interface 736 identifiers and identifiers for virtualized firewalls or NATs. 738 7.8. APPLICATION_ID 740 typedef struct { 741 uint16_t id_no; 742 char version[14]; 743 } application_id_t; 745 The APPLICATION_ID is a mechanism for identifying the application for 746 which the resources (firewall pinholes, NAT table mappings) are being 747 requested. It is expected that the information will be used as input 748 to a policy-based decision whether or not to grant the request. 750 The id_no member represents the application itself. It MUST use the 751 well-known port number, allocated by the IANA, for the application. 752 In the case where there is no well- known port, such as a Cisco- 753 proprietary protocol for which no well-known port has been requested, 754 a number outside the IANA registered port range MUST be allocated. 756 There are cases in which a protocol uses a dynamically allocated port 757 number -- for example, non-tunneled H.245 or RTP. In those cases the 758 application_id SHOULD be that of the parent protocol (say, H.225 in 759 the case of H.245 or SIP or RTSP in the case of RTP). 761 The version field carries a null-terminated ASCII representation of 762 the version number. If the version string is 14 octets long no null 763 termination is necessary; if the version string is more than 14 764 octets in length it MUST be truncated to 14 octets. For example, 765 version "6" would appear: 767 1 2 3 4 768 +-------------+-------------+-------------+-------------+ 769 0 | 0x36 | 0x00 | | | 770 +-------------+-------------+-------------+-------------+ 771 1 | | | | | 772 +-------------+-------------+-------------+-------------+ 773 2 | | | | | 774 +-------------+-------------+-------------+-------------+ 775 | | | | | 776 +-------------+-------------+-------------+-------------+ 778 while version "3rev1 beta" would be represented as: 780 1 2 3 4 781 +-------------+-------------+-------------+-------------+ 782 0 | 0x33 | 0x72 | 0x65 | 0x76 | 783 +-------------+-------------+-------------+-------------+ 784 1 | 0x31 | 0x20 | 0x62 | 0x65 | 785 +-------------+-------------+-------------+-------------+ 786 2 | 0x74 | 0x61 | 0x00 | | 787 +-------------+-------------+-------------+-------------+ 788 | | | | | 789 +-------------+-------------+-------------+-------------+ 791 8. Traffic Flows 793 A flow is defined as a set of IP packets passing through a particular 794 point in the network that match one or more IPV4_SELECTOR or 795 IPV6_SELECTOR elements. A selector A matches a packet P when the 796 following seven conditions hold: 798 1. (A.src_addr AND A.src_mask) equals (P.src_addr AND A.src_mask) 800 2. (A.dst_addr AND A.dst_mask) equals (P.dst_addr AND A.dst_mask) 802 3. A.src_port_lo <= P.src_port 804 4. A.src_port_hi >= P.src_port 806 5. A.dst_port_lo <= P.dst_port 808 6. A.dst_port_hi >= P.dst_port 810 7. A.protocol equals P.protocol, or A.protocol equals zero. 812 When the src_addr or dst_addr of a selector is zero, the selector 813 will match any source address or destination address, respectively. 814 Similarly, a selector with a protocol value of zero will match any 815 protocol. In the future, additional selector TLVs may be defined in 816 order to express additional information (such as TCP or IP options or 817 MPLS labels) or to express a particular sort of flow more compactly 818 (such as the UDP port pairs often used in RTP). However, any 819 additional selector TLVs will describe what the traffic flow of 820 interest is, and will not describe what should be done with it. If, 821 for example, a controller needs to express that a particular flow 822 should have QoS applied to it, or should be rate-limited, or should 823 be monitored or audited, then the specification of the responder 824 behavior with respect to the traffic flow MUST be expressed using TLV 825 elements that are separate from the selector elements. 827 9. Responder Discovery 829 In some cases, the initiator may need to open a pinhole, but not know 830 the responder to which the Open Pinhole exchange should be addressed. 831 The authorization interception feature can be used to find the 832 appropriate firewall, in some cases. 834 A network device that implements the authorization system has the 835 capability of intercepting packets that it is forwarding, and acting 836 on those packets if appropriate, and forwarding them otherwise. A 837 firewall implementing the Authorized IP Firewall Control application 838 MAY intercept Start messages for that application. An initiator MAY 839 send an Authorized IP Firewall Control message addressed to an end 840 host behind a responder onto which a pinhole should be installed. 842 Note that in order to discovery multiple nested firewalls, a firewall 843 implementing Start message interception SHOULD forward the Start 844 message on towards its destination. 846 This firewall discovery method will work only when the responder is 847 on both the path from the initiator to the end host and the path(s) 848 from the end host to the other devices to which it intends to 849 communicate over the pinhole. When a network is multi-homed, this 850 may not be the case. 852 10. Authorizations 854 We define the following TLV formats, for native authorization: 856 The FW_CTL TLV format has a zero-length Value field. It grants 857 permission to its holder to control responders to allow the flow of 858 traffic described by the TLV elements that follow it. If there are 859 no flow-description elements that follow it, then a FW_CTL element 860 does not actually convey any authorizations. For example, the 861 statement 863 FW_CTL IPV4_SELECTOR1 IPV4_SELECTOR2 865 grants permission to control any responder to permit the flow of 866 traffic described by the two selector elements that follow it. 868 The FW TLV format has a zero-length Value field. It grants 869 permission to its holder to act as a responder for the traffic 870 described by the TLV elements that follow it. If there are no flow- 871 description elements that follow a FW element, then the element 872 conveys no authorizations. For example, the statement 874 FW IPV4_SELECTOR1 IPV4_SELECTOR2 IPV4_SELECTOR3 876 grants permission to act as a responder and control the flow of 877 traffic described by the three selector elements that follow it. 879 A single authorization element MAY contain both a FW_CTL element and 880 a FW element. Formally, the authorizations have the format 882 ((FW IPV4_SELECTOR+)|(FW_CTL IPV4_SELECTOR+))+ 884 using the notation described above. 886 We say that selector A contains selector B, or B is contained by A, 887 whenever every packet that matches selector B also matches selector 888 A. This situation occurs if and only if all of the following 889 conditions hold: 891 1. (A.src_addr AND A.src_mask) equals (B.src_addr AND A.src_mask) 893 2. (A.dst_addr AND A.dst_mask) equals (B.dst_addr AND A.dst_mask) 895 3. A.src_port_lo <= B.src_port_lo 897 4. A.src_port_hi >= B.src_port_hi 898 5. A.dst_port_lo <= B.dst_port_lo 900 6. A.dst_port_hi >= B.dst_port_hi 902 7. A.protocol equals B.protocol, or A.protocol equals zero. 904 Note that if A contains B, it is not necessarily true that B contains 905 A. However, if A contains B and B contains C, then it follows that A 906 contains C. 908 When checking authorizations against requests, a responder MUST 910 o verify that the selector describing the authorizations granted by 911 the server to the initiator (I_AUTHS) are contained in the 912 server's authorizations. 914 o verify that the selector describing the initiator's request is 915 contained in the selector describing the authorizations granted by 916 the server to the initiator. 918 A future version of this specification may contain other 919 authorization elements. 921 11. NAT discussion 923 It may be the case that the firewall being controlled is co-resident 924 with a NAT or that there is a NAT between the controller and the 925 firewall. It may also be the case that we are controlling a stand- 926 alone NAT. This raises some issues, some of which are addressed in 927 this document and some of which are for future study. 929 11.1. Stand-alone NAT 931 This is straightforward -- we send requests to the NAT and the NAT 932 returns the external address, allowing us to use the external address 933 in protocols that make use of embedded addresses, such as VoIP 934 protocols or streaming media protocols. 936 The behavior of the Authorized IP firewall control protocol is the 937 same whether it is being used to control NATs or firewalls, with the 938 difference lying in the data elements. 940 11.2. The NAT is co-resident with the firewall 942 In this scenario the firewall should be treated as a stand-alone NAT. 943 That is to say, the data elements will include the NAT_TUPLE in the 944 Request and the NAT_INFO in the Response. The reason for this is 945 that it is assumed that an application would not want an external 946 address if it did not also want a firewall pinhole, and it would want 947 both resources to have the same lifetime. 949 When the Request arrives at the NAT/firewall device, the device MUST 950 process the NAT request first, and the results of the NAT processing 951 (that is to say, the NAT table mapping) passed to the firewall 952 function as part of the pinhole descriptor. If the NAT table mapping 953 is not acquired first and used in the filter description, the filter 954 rule that will be installed not be correct for processing inbound 955 (external->internal) traffic. 957 The firewall pinhole for outbound traffic will contain: 959 Source address: untranslated internal address 961 Source port: untranslated internal port 963 Destination address: untranslated peer address 965 Destination port: untranslated peer port 967 The firewall pinhole for inbound traffic will contain: 969 Source address: untranslated peer address 971 Source port: untranslated peer port: 973 Destination address: translated (external) address 975 Destination port: translated (external) port 977 11.3. There is a NAT between the controller and the firewall 979 The issue here is that NAT is transparent to the endpoint. In the 980 typical case an endpoint does not know whether or not there is a NAT 981 along the path between it and its peer. Even if communication fails 982 the endpoint cannot know whether the failure was caused by a NAT 983 interaction or some other network failure. When a NAT is present an 984 endpoint will not know the external address, which is the correct 985 one, to send in a pinhole request. A pinhole descriptor will contain 986 the endpoint's local address and port (the address on the network 987 interface card and the port number assigned by the local TCP or UDP 988 stack). In the case where a NAT is present between an endpoint and 989 the firewall on which it's requesting a pinhole, the address and port 990 local to the endpoint are not the address and port visible outside 991 the NAT, and the pinhole descriptor will not reflect that. The 992 pinhole will be for the "wrong" internal address. 994 12. NAT call flow examples 996 Below we show some sample SIP call flows, using the Authorized IP FW 997 Control application to acquire NAT table mappings (and open pinholes 998 if appropriate) to provide traversal capabilities. In all cases the 999 SIP messages are shown in black and the AFWC messages are shown in 1000 red. These call flows assume the use of a 4-message exchange, which 1001 may be reduced to two messages in future versions of this document. 1002 In these examples, the endpoints or their call control servers always 1003 function as initiators and the NATs always function as responders. 1005 Because SIP (and, for that matter, H.323, RTSP, and other session- 1006 oriented protocols) embed addresses in signaling messages it is 1007 necessary to acquire NAT table mappings before sending an INVITE 1008 (calling party) or a 200 OK (called party). In firewall-only 1009 applications the request may be made before or after the signaling 1010 message is sent, however that entails risking that the application 1011 signaling progresses even if firewall resources are not available. 1013 In these examples and in actual use, the endpoint (or its agent, such 1014 as a call control server) will generally request NAT table entries 1015 only for the address/port tuples on which it will be listening for 1016 incoming media. The case in which requests must be made for mappings 1017 for outbound media is that in which the NAT does not automatically 1018 allocate mappings for new outbound data streams [ETH] i.e. the NAT is 1019 entirely controlled and only creates mappings on explicit request. 1021 In the exceptional case that the NAT is symmetric, both internal and 1022 external addresses will need to be installed to describe a mapping. 1024 12.1. Calling endpoint is NATted, controls firewall 1026 In this example the calling party is NATted but is routing signaling 1027 through a call control server. It is sending AFWC messages to the 1028 firewall itself. For the sake of simplicity the call flow shows the 1029 signaling being sent directly to the called party, however in actual 1030 use it is likely that the signaling would be sent to the called 1031 party's call control server. 1033 Calling Caller's Caller's Called 1034 endpoint NAT CCS Party 1036 | start | | | 1037 |------------->| | | 1038 | | | | 1039 | offer | | | 1040 |<-------------| | | 1041 | | | | 1042 | request | | | 1043 |------------->| | | 1044 | | | | 1045 | response | | | 1046 |<-------------| | | 1047 | | | | 1048 | INVITE | | | 1049 |=============> INVITE | | 1050 | |==============>| INVITE | 1051 | | |===========>| 1052 | | | | 1053 | | | | 1054 | | | 200 OKAY | 1055 | | |<===========| 1056 | 200 OKAY | | 1057 |<=============================| | 1058 | | | | 1059 | | | | 1061 12.2. Calling endpoint is NATted, CCS controls firewall 1063 In this example the calling endpoint is NATted, as well, however the 1064 call control server is sending AFWC requests to the firewall/NAT. 1065 Note that in this example the call control server is topologically 1066 "outside" the firewall, which has implications for assumptions about 1067 trust relationships and suggests that the notion of a "trusted 1068 interface" cannot be relied upon in this case. 1070 Calling Caller's Caller's Called 1071 endpoint NAT CCS Party 1073 | INVITE | | 1074 |=============================>| | 1075 | | | | 1076 | | start | | 1077 | |<--------------| | 1078 | | | | 1079 | | offer | | 1080 | |-------------->| | 1081 | | | | 1082 | | request | | 1083 | |<--------------| | 1084 | | | | 1085 | | response | | 1086 | |-------------->| | 1087 | | | | 1088 | | | INVITE | 1089 | | |===========>| 1090 | | | | 1091 | | | 200 OKAY | 1092 | | |<===========| 1093 | 200 OKAY | | 1094 |<=============================| | 1095 | | | | 1096 | | | | 1098 12.3. Called endpoint NATted 1100 In this case the called party is NATted but its call control server 1101 is accessible. The INVITE is sent to the called party's call control 1102 server, which forwards it to the called party. Note that the call 1103 control server cannot use AFWC to acquire a NAT table mapping until 1104 it has received the 200 response from the called endpoint; this is 1105 because it needs to send the address/port tuple on which the endpoint 1106 expects to receive media as part of the AFWC request. 1108 Calling Called party's Called Party's Called 1109 endpoint CCS NAT Party 1111 | INVITE | | | 1112 |=============> | | 1113 | | INVITE | 1114 | |===========================>| 1115 | | | | 1116 | | 200 OKAY | 1117 | |<===========================| 1118 | | | | 1119 | | start | | 1120 | |-------------->| | 1121 | | | | 1122 | | offer | | 1123 | |<--------------| | 1124 | | | | 1125 | | request | | 1126 | |-------------->| | 1127 | | | | 1128 | | response | | 1129 | |<--------------| | 1130 | | | | 1131 | | | | 1132 | 200 OKAY | | | 1133 |<=============| | | 1134 | | | | 1135 | | | | 1137 13. Failover 1139 This application does not define its own failover system, and instead 1140 recommends that firewalls use the failover mechanisms that they have 1141 in place. A firewall may not be able to retain pinholes across 1142 reboots. However, if the firewall implements a checkpointing or 1143 standby feature, the pinholes SHOULD be included in the state that is 1144 checkpointed or duplicated on the standby system. The AFWC protocol 1145 allows for a hot-standby system by allowing one device to respond on 1146 behalf of another (assuming that the standby device is properly 1147 authenticated and authorized). This feature should allow existing 1148 standby systems to implement the AFWC without any additional changes. 1150 It may be desirable to introduce a secure mechanism by which a 1151 controller can discover if a firewall has reloaded. One way to do 1152 this would be to use a 128-bit EPOCH value, which the firewall 1153 selects randomly at boot time. By including an EPOCH element in the 1154 Offer, the firewall could securely convey the current epoch to the 1155 controller. By retaining and comparing epoch values, a controller 1156 can detect if a firewall has reloaded. 1158 14. Security Considerations 1159 Appendix A. Acknowledgements 1161 The authors would like to thank Raghu Gyambavantha, Eric Wang, and 1162 Jan Vilhuber for their comments and suggestions. 1164 Authors' Addresses 1166 Melinda Shore 1167 Cisco Systems 1168 809 Hayts Road 1169 Ithaca, New York 14850 1170 USA 1172 Email: mshore@cisco.com 1174 David A. McGrew 1175 Cisco Systems 1176 510 McCarthy Blvd 1177 Milpitas, California 95035 1178 USA 1180 Email: mcgrew@cisco.com 1182 Intellectual Property Statement 1184 The IETF takes no position regarding the validity or scope of any 1185 Intellectual Property Rights or other rights that might be claimed to 1186 pertain to the implementation or use of the technology described in 1187 this document or the extent to which any license under such rights 1188 might or might not be available; nor does it represent that it has 1189 made any independent effort to identify any such rights. Information 1190 on the procedures with respect to rights in RFC documents can be 1191 found in BCP 78 and BCP 79. 1193 Copies of IPR disclosures made to the IETF Secretariat and any 1194 assurances of licenses to be made available, or the result of an 1195 attempt made to obtain a general license or permission for the use of 1196 such proprietary rights by implementers or users of this 1197 specification can be obtained from the IETF on-line IPR repository at 1198 http://www.ietf.org/ipr. 1200 The IETF invites any interested party to bring to its attention any 1201 copyrights, patents or patent applications, or other proprietary 1202 rights that may cover technology that may be required to implement 1203 this standard. Please address the information to the IETF at 1204 ietf-ipr@ietf.org. 1206 Disclaimer of Validity 1208 This document and the information contained herein are provided on an 1209 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1210 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1211 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1212 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1213 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1214 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1216 Copyright Statement 1218 Copyright (C) The Internet Society (2006). This document is subject 1219 to the rights, licenses and restrictions contained in BCP 78, and 1220 except as set forth therein, the authors retain all their rights. 1222 Acknowledgment 1224 Funding for the RFC Editor function is currently provided by the 1225 Internet Society.