idnits 2.17.1 draft-carlson-nhrp-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 6) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Abstract' ) ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security' ) ** 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.) ** There are 5 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [2,3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? '1' on line 401 looks like a reference -- Missing reference section? '2' on line 403 looks like a reference -- Missing reference section? '3' on line 406 looks like a reference -- Missing reference section? '4' on line 408 looks like a reference -- Missing reference section? '5' on line 410 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Carlson 2 ANL 3 L. Winkler 4 ANL 5 August, 1999 7 Guidelines for Next Hop Client (NHC) Developers 8 10 1. Status of this memo 12 This document is an Internet-Draft and is in full 13 conformance with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet 15 Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by 21 other documents at any time. It is inappropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as "work in progress". 25 To view the entire list of current Internet-Drafts, please 26 check the "lid-abstracts.txt" listing contained in the 27 Internet-Drafts Shadow Directories on ftp.is.co.za 28 (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it 29 (Southern Europe), munnari.oz.au (Pacific Rim), 30 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West 31 Coast). 33 2. Abstract 35 This document provides guidelines for developers of the 36 Next Hop Resolution Protocol Clients (NHC). It assumes 37 that the clients are directly connected to an ATM based 38 NBMA network. The same principles will apply to clients 39 connected to other types of NBMA networks. The intent is 40 to define the interaction between the NHC code and the 41 TCP/IP protocol stack of the local host operating system. 42 The NHC is capable of sending NHRP requests to a Next Hop 43 Resolution Protocol Server (NHS) to resolve both inter and 44 intra LIS addresses. The NHS reply may be positive (ACK) 45 indicating a short-cut path is available or negative (NAK) 46 indicating that a shortcut is not available and the routed 47 path must be used. The NHC must cache (maintain state) for 48 both the ACK and NAK replies in order to use the correct 49 shortcut or routed path. The NAK reply must be cached to 50 avoid making repeated requests to the NHS when the routed 51 path is being used. 53 3. Overview 55 In the Classical IP over ATM model [1], an ATM attached 56 host communicates with an ATMARP server to resolve IP to 57 ATM address semantics. This model supports the concept of 58 a Logical IP Subnet (LIS) with intra LIS communications 59 using direct PVCs/SVCs and inter LIS communications using 60 IP routers to forward packets. This model easily maps to 61 the conventional LAN model of subnets and routers. The 62 Next Hop Resolution Protocol (NHRP) [2] defines how the LIS 63 model can be modified to allow direct ATM SVCs (shortcut 64 paths) for inter LIS traffic. With NHRP, nodes directly 65 attached to an ATM network can bypass the IP routers and 66 establish a direct switched virtual circuit to improve 67 performance when needed. 69 The NHS code replaces the ATMARP code in the ATMARP server. 70 Each NHS serves a set of destination client hosts and 71 cooperates with other NHSs to resolve NHRP next hop 72 requests within their own logical ATM network. The NHC to 73 NHS and NHS to NHS protocol interactions are described in 74 [2]. Other documents in the NHRP series define the general 75 applicability [3] and the transition from ATMARP servers to 76 NHSs [4]. 78 The NHC code replaces the ATMARP code in the local 79 workstations. This code will take the destination IP 80 address and map it into the ATM End Station Address (AESA) 81 for both intra and inter LIS destinations. The returned 82 AESA will be stored in a local cache table. In addition to 83 storing the positive replies, the NHC will need to store 84 the negative replies to avoid making repeated NHS calls 85 when using the routed path. 87 This document describes a base line method for caching the 88 returned information. Other methods may be used as long as 89 the same functionality is provided. 91 4. IP Processing 93 In the Classical IP LIS model [1] the TCP/IP protocol stack 94 treats the ATM network as a simple data link layer 95 protocol. When an application sends data using the 96 Classical IP protocol, IP performs a routing table lookup 97 to determine if the destination is reachable via a local 98 interface or whether an intermediate router is the next hop 99 to the IP destination. 101 If the destination is found to be local (e.g. in the same 102 LIS as the source) the packet will be passed to the local 103 ATM interface with the next hop IP address set to the 104 destination nodes IP address. At this point the ATMARP 105 table will be searched to determine the ATM Address of the 106 destination node. If no ATMARP table entry is found an 107 ATMARP request will be sent to the ATMARP server. This 108 server can reply with a positive (ACK) or negative (NAK) 109 answer depending on the current information it has in its 110 cache. If an ACK is received the host's local ATMARP table 111 is filled in appropriately and the source is now able to 112 send IP datagrams to the destination. If a NAK is 113 returned, the calling application is notified of this error 114 condition (e.g., ICMP destination unreachable). 116 If the destination is found to be remote (e.g., in a 117 different LIS from the source) the IP address of the next 118 hop router is extracted from the IP routing table and the 119 ATM Address of this router is looked up in the ATMARP 120 table. Since the router is in the same LIS as the source 121 node, the ATMARP procedure described above will find the 122 correct ATM Address or the packet will be marked as 123 undeliverable and the user application will be notified of 124 the error. 126 The ATMARP service functions exactly as the existing ARP 127 service provided on Ethernet broadcast networks. Since the 128 ARP service will only try and resolve addresses for nodes 129 that are in a single IP subnet, the ARP table only needs to 130 keep positive answers. No state information is retained 131 about failed mappings. 133 5. NHC Processing 135 In this section we briefly describe what is required in 136 order for a host to take advantage of shortcuts through the 137 ATM network. On the host, a NHC process initiates various 138 NHRP requests in order to obtain access to the NHRP 139 service. Within the ATM subnetwork, the ATMARP server is 140 replaced with a NHS. As defined in [4] the NHS is required 141 to respond to both ATMARP and NHRP Resolution requests. In 142 the nodes wishing to take advantage of shortcut paths 143 across the ATM subnetwork, the ATMARP client code must be 144 replaced with NHC code. This allows the source node to ask 145 for the ATM AESA of both local and remote nodes. Finally 146 the source node must be modified to know when it should ask 147 for the ATM AESA of a remote node and when the local LIS 148 router should be used. These modifications are described 149 in the remainder of this document. 151 The protocol processing described in [2] states a source 152 may query a NHS for the ATM AESA of a destination node. 153 However as is pointed out in [5], to achieve shortcut paths 154 through the ATM network, it is not enough to simply replace 155 the ATMARP client code with the NHC code. This is because 156 the source host will never ask the NHS for the ATM AESA of 157 a node in a remote LIS. When the source consults the IP 158 routing table, it performs the local/remote test, before 159 the NHC code is processed. As a result, the IP address of 160 the next hop router will be used by the NHC instead of the 161 IP address of the remote (inter LIS) host. The NHC code 162 must ignore the result of the IP routing table lookup and 163 perform its own local/remote test. 165 The NHC must perform the following functions: 166 1. Test to see if the destination node is `local' to 167 this LIS. If so use the existing ATMARP rules 168 described in [1]. 169 2. If not; send an NHRP message to the local NHS and 170 attempt to setup a `shortcut' path. If successful; 171 save the IP to ATM AESA mapping in the local NHC 172 cache. 173 3. If not successful; use the routed path and save 174 this state in the NHC cache so future requests 175 don't test for a shortcut again. 176 4. Allow user application to override system default 177 operation and explicitly request a shortcut or 178 routed path for a flow. 180 It is required that this routed path state will be 181 maintained in the same manner as the existing ATMARP 182 service. That is a timer will be used to expire old 183 information and some administrative function exists to 184 manually delete data if needed. 186 6. Need for State 188 It is obvious that the IP to ATM AESA mappings should be 189 maintained in a local cache to improve network performance. 190 This soft state is maintained in today's ARP and ATMARP 191 systems using timers to purge old or unused data. The NHC 192 will maintain both inter and intra LIS IP to ATM Address 193 mappings in the same manner. It may be less obvious that 194 an NHC will also need to maintain this same soft state for 195 inter LIS mappings using the routed path. If this state is 196 not maintained, the source node will send requests to the 197 NHS asking if a shortcut path can be setup every time a 198 packet is sent over the routed path. 200 Some of the features of this state are: 201 1. Cache lookups must be fast as they are done on 202 every packet. 203 2. The cache lookup must be on the destination IP 204 address instead of the next-hop router IP 205 address. 206 3. Both ACK and NAK data should be cached for the 207 length of the holding time parameter in the NHRP 208 response. 210 Since state must be maintained, the questions of where to 211 maintain it, how to manually managed it, and how to 212 selectively override it need to be addressed. No matter 213 where this state information is kept, a method for manually 214 examining and changing this state information must be 215 provided. This is essential to insure that the network is 216 operating properly. 218 There are several possible locations for storing this state 219 information, they are: 220 1. Store state in the `ARP' table. This is the 221 traditional location for this IP to ATM address 222 mappings. This table must be extended to handle 223 the caching of negative (routed path) information. 224 This solution provides a system wide service that 225 may be used by the NHC. 226 2. Store state in the IP routing table. This is the 227 traditional location for the local/remote state 228 information. 229 3. Store state in an ATM MIB structure. This is the 230 traditional location for storing ATM VCC data. It 231 also provides a system wide service that is geared 232 toward ATM services. This avoids munging the 'ARP' 233 table to hold negative data. 234 4. Store state in the TCP Process Control Block. This 235 allows a per process tailoring of shortcut or 236 routed path information. This works well for TCP 237 connections, but not UDP style services. 238 5. Store state in the socket structure. This also 239 allows per process tailoring of the state 240 information. 241 6. Store state in a newly defined table. 243 The NHC should also support both local (per-process) and 244 global (per-system) state. This would allow a system wide 245 default while allowing a specific application to tailor the 246 operation for a specific task. For example assume a site 247 runs both a DNS server and FTP server on a single host. 248 Inter LIS communications to the DNS server should take the 249 routed path to avoid setup overhead. While an FTP session 250 would benefit from the shortcut path to improve 251 performance. Supporting both operations from a single 252 client will require both a global state (e.g. use shortcut 253 for FTP) and a local state (e.g. use routed path for DNS). 255 6.1 Using TCP 257 TCP is a connection orientated protocol that provides per- 258 process state information using a TCP Protocol Control 259 Block (PCB). This PCB can be used to save the 260 shortcut/routed path state information. Using a quad-state 261 flag that shows the USE_SHORT_CUT, TRY_SHORT_CUT, 262 USE_ROUTED_PATH, or TRY_ROUTED_PATH states would allow each 263 process to use the service it chooses. The advantage of 264 this approach is that it allows per flow control over the 265 use of the shortcut or routed path. The disadvantage is 266 that this PCB is only created for TCP connections. UDP 267 connections will only use the system default action. 269 A second option is to store this information in the socket 270 PCB and use the socket function (setsockopt) to save this 271 information. This option will allow both TCP and UDP 272 applications to set a per flow action to override the 273 system default operation. To enable this option, the IP 274 kernel code will need to be modified to allow this quad- 275 state flag to be set. In addition this flag will need to 276 be checked when each packet is sent to determine the if the 277 shortcut or routed path is being used. 279 6.2 Using UDP 281 UDP is a connectionless orientated protocol that doesn't 282 provide any support for state information. It relies on 283 the application to provide the necessary state information. 284 In this case where should the state be stored? The user 285 application could store this itself and pass this down to 286 the kernel in some manner. Another option is to store this 287 information in an ATM MIB structure. A third option is to 288 allow a socket option (setsockopt) that the user 289 application can set to override the default behavior. 291 6.3 Using ICMP 293 In keeping with the tradition of using ICMP echo packets 294 for Internet management functions (e.g. ping, traceroute) 295 then it will be necessary to allow these applications to 296 run over the shortcut and routed paths. The user will need 297 to be able to specify which path to use and a default 298 action needs to be defined too. 300 7. Conclusions 302 NHRP provides new services and functionality for IP nodes 303 using ATM networks. To use these services the client must 304 store state information that describes whether a 305 destination node is reachable via a shortcut or a routed 306 path. 308 The state information should be stored on a global per- 309 application basis with per-process override functionality. 310 This allows short lived functions (e.g. DNS requests) and 311 long lived requests (e.g. ftp sessions) to use different 312 paths. Storing state only based on the destination address 313 means that all processes must use the same path and this 314 creates unreasonable demands on the network. To accomplish 315 this the /etc/services file should be modified to carry a 316 new flag to indicate the per-application default (shortcut 317 vs. routed path) behavior. 319 This state information is required to avoid having the 320 client make a call to the NHS for every packet it sends 321 along the routed path. It is recommended that the IP 322 routing table be modified to support a new flag. This flag 323 will indicate whether the NHS returned an ACK or NAK to the 324 NHRP request. 326 In addition, application programmers and system 327 administrators require the ability to explicitly request a 328 specific service (e.g. use the routed path or shortcut 329 path). This includes the ability to verify network 330 operation by specifying how ICMP echo requests (e.g. ping, 331 traceroute) are handled. The NHC must support the manual 332 setting of this state information. A new socket option 333 that allows the user to specify the operation needs to be 334 supported. 336 To support this capability a new socket option will be 337 created to allow the user application to control the 338 operation of a particular connection (flow). This option 339 will allow the user to specify that a connection use one of 340 the following: 341 * USE_SYSTEM_DEFAULT. Use the shortcut or routed 342 path based on the system configuration information 343 for this application. (This is the default 344 behavior.) 345 * USE_SHORT_CUT. If a shortcut path exists, then use 346 it to deliver the data. If it doesn't exist, then 347 try and create it. If the shortcut cannot be 348 created, fail the connection and notify the user. 349 * TRY_SHORT_CUT. If a shortcut path exists, then use 350 it to deliver the data. If it doesn't exist, then 351 try and create it. If the shortcut cannot be 352 created, try using the routed path. 353 * USE_ROUTED_PATH. Use the routed path regardless of 354 whether a shortcut exists or not. 355 * TRY_ROUTED_PATH. If a shortcut doesn't exist, 356 don't try and create it, use the routed path 357 instead. 359 8. Security 361 The security issues for NHRP are addressed in other NHRP 362 documents [2,3]. Some specific security issues for the NHC 363 developer are discussed below. 365 * Address spoofing at the IP or ATM layer may allow an 366 attacker to hi-jack an IP connection or service. 367 This threat may be reduced by limiting the scope of 368 the ATM routing domain. In this way only trusted IP 369 hosts will be able to reach and use the services of 370 the NHS. 371 * Denial of service attacks may be launched at both 372 the IP and ATM layers of the NHS. At the ATM layer, 373 the attacker may repeatedly generate signaling 374 messages that consuming system resources thus 375 preventing NHCs from using the NHS services. At the 376 IP layer, the attacker may register false IP to ATM 377 mappings thus preventing a NHC from registering the 378 correct IP to ATM mapping. 379 * When a NHC creates or accepts a short-cut path it 380 bypasses the site border router. Therefore, any 381 security features in the border router are also 382 bypassed. This threat may be reduced by limiting 383 the scope of the ATM routing domain, increasing 384 security features in the NHC host, allowing the NHS 385 to evaluate security features when short-cut paths 386 are requested or a compination of all of these 387 methods. 389 9. Authors Address 391 Richard Carlson 392 Argonne National Laboratory 393 RACarlson@anl.gov 395 Linda Winkler 396 Argonne National Laboratory 397 lwinkler@anl.gov 399 10. References: 401 [1] "Classical IP and ARP over ATM", RFC-2225, M. Laubach 402 J. Halpern, April 1998. 403 [2] "NBMA Next Hop Resolution Protocol (NHRP)", RFC-2332, 404 J. Luciani D. Katz D. Piscitello B. Cole N. Doraswamy, 405 April 1998. 406 [3] "NHRP Protocol Applicability Statement", RFC-2333, D. 407 Cansever, April 1998. 408 [4] "Classical IP to NHRP Transition", RFC-2336, J. 409 Luciani, July 1998. 410 [5] "Local/Remote Forwarding Decision in Switched Data link 411 Subnetworks", RFC-1937, Y. Rekhter & D. Kandlur, May 1996.