idnits 2.17.1 draft-ietf-mobileip-tunnel-reverse-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 196: '...sets the 'T' bit MUST support the two ...' RFC 2119 keyword, line 251: '...Tunnel Extension MUST NOT be included ...' RFC 2119 keyword, line 308: '... [1], the mobile node MAY try zeroing the 'T' bit, eliminating...' RFC 2119 keyword, line 314: '... the mobile node MAY try zeroing the '...' RFC 2119 keyword, line 323: '...g with a co-located address, it SHOULD...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 218 has weird spacing: '... agents proba...' -- 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 (January 31, 1996) is 10311 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) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-05 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1826 (ref. '6') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. '7') (Obsoleted by RFC 2406) == Outdated reference: A later version (-02) exists of draft-ferguson-ingress-filtering-01 Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Montenegro 3 INTERNET DRAFT Sun Microsystems, Inc. 4 January 31, 1996 6 Reverse Tunneling for Mobile IP 7 draft-ietf-mobileip-tunnel-reverse-00.txt 9 Status of This Memo 11 This document is a submission by the Mobile IP Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the Working Group mailing list at "mobile-ip@SmallWorks.COM". 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet- Drafts as 25 reference material or to cite them other than as ``work in 26 progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 30 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 Mobile IP uses tunneling from the home agent to the mobile node's 37 care-of address, but rarely in the reverse direction. Usually, a 38 mobile node sends its packets through a router on the foreign net, 39 and assumes that routing is independent of source address. When 40 this assumption is not true, it is convenient to establish a 41 topologically correct reverse tunnel from the care-of address to the 42 home agent. 44 This document proposes backwards-compatible extensions to Mobile IP 45 in order to support topologically correct reverse tunnels. This 46 document does not attempt to solve the problems posed by firewalls 47 located between the home agent and the mobile node's care-of 48 address. 50 1. Introduction 52 Section 1.3 of the Mobile IP specification [1] lists the following 53 assumption: 55 It is assumed that IP unicast datagrams are routed based on the 56 destination address in the datagram header (i.e., not by source 57 address). 59 Because of security concerns (e.g. IP spoofing attacks), and in 60 accordance with the IAB [8] and CERT [3] advisories to this effect, 61 routers that break this assumption are increasingly more common. 63 In the presence of such routers, the source and destination IP 64 address in a packet must be topologically correct. The forward 65 tunnel complies with this, as its endpoints (home agent address and 66 care-of address) are properly assigned addresses for their 67 respective locations. On the other hand, the source IP address of a 68 packet transmitted by the mobile node does not correspond to the 69 location from where it emanates. 71 This document discusses topologically correct reverse tunnels. 73 Mobile IP does dictate the use of reverse tunnels in the context of 74 multicast datagram routing and mobile routers. However, the source 75 IP address is set to the mobile node's home address, so these 76 tunnels are not topologically correct. 78 Notice that there are several uses for reverse tunnels regardless of 79 their topological correctness: 81 - Mobile routers: reverse tunnels obviate the need for recursive 82 tunneling [1]. 84 - Multicast: reverse tunnels enable a mobile node away from home 85 to (1) join multicast groups in its home network, and (2) 86 transmit multicast packets such that they emanate from its home 87 network [1]. 89 - The TTL of packets sent by the mobile node (particularly when 90 it addresses other hosts in its home network) may be so low 91 that they may expire before reaching their destination. A 92 reverse tunnel solves the problem as it represents a TTL 93 decrement of one [5]. 95 1.1. Terminology 97 The discussion below uses terms defined in the Mobile IP 98 specification. Additionally, it uses the following terms: 100 Forward Tunnel 102 A tunnel that shuttles packets towards the mobile node. It 103 starts at the home agent, and ends at the mobile node's 104 care-of address. 106 Reverse Tunnel 108 A tunnel that starts at the mobile node's care-of address and 109 terminates at the home agent. 111 Light-weight mobile node 113 A mobile node that relies on a separate foreign agent for 114 tunneling services (i.e. the care-of address belongs to the 115 foreign agent). 117 1.2. Assumptions 119 Mobility is constrained to one IP address space (e.g. the routing 120 fabric between, say, the mobile node and the home agent is not 121 partitioned into a "private" and a "public" network). 123 This document does not attempt to solve the firewall traversal 124 problem. Rather, it assumes one of the following is true: 126 - There are no intervening firewalls along the path of the 127 tunneled packets. 129 - Any intervening firewalls share the security association 130 necessary to process any authentication [6] or encryption [7] 131 headers which may have been added to the tunneled packets. 133 The reverse tunnels considered here are symmetric, that is, they use 134 the same configuration (encapsulation method, IP address endpoints) 135 as the forward tunnel. IP in IP encapsulation [2] is assumed unless 136 stated otherwise. 138 Route optimization [4] introduces forward tunnels initiated at a 139 correspondent host. Since a mobile node cannot know if the 140 correspondent host can decapsulate packets, reverse tunnels in that 141 context are not discussed here. 143 1.3. Justification 145 Why not let the mobile node itself initiate the tunnel to the home 146 agent? This is indeed what it should do if it is already operating 147 with a topologically significant co-located address. 149 However, one of the primary objectives of the Mobile IP 150 specification is to not *require* this mode of operation. 152 The mechanisms outlined in this document are primarily intended for 153 use by mobile nodes that rely on the foreign agent for forward 154 tunnel support. It is desirable to continue supporting these 155 "lightweight" mobile nodes, even in the presence of filtering 156 routers. 158 2. Overview 160 A light-weight mobile node arrives at a foreign net, listens for 161 advertisements and selects a foreign agent that supports reverse 162 tunnels. It requests this service when it registers through the 163 selected foreign agent. At this time, and depending on how the 164 mobile node wishes to deliver packets to the foreign agent, it also 165 requests either the lightweight or the encapsulating style of 166 delivery (section 5). 168 In the lightweight delivery style, the mobile node designates the 169 foreign agent as its default router and proceeds to send packets as 170 usual. The foreign agent intercepts them, and tunnels them to the 171 home agent. 173 In the encapsulating delivery style, the mobile node encapsulates 174 all its outgoing packets to the foreign agent. The foreign agent 175 decapsulates and tunnels again, this time, directly to the home 176 agent. 178 3. New Packet Formats 180 3.1. Agent Advertisements: Mobile Service Extension 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type | Length | Sequence Number | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Lifetime |R|B|H|F|M|G|V|T| reserved | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | zero or more Care-of Addresses | 189 | ... | 191 The only change to the Mobile Service Extension [1] is the 192 additional 'T' bit: 194 T Agent offers reverse tunneling service. 196 A foreign agent that sets the 'T' bit MUST support the two delivery 197 styles currently supported (section 5). 199 Using this information, a mobile node is able to choose a foreign 200 agent that supports reverse tunnels. Notice that if a mobile node 201 does not understand this bit, it simply ignores it. 203 3.2. Registration Request 205 Reverse tunneling support is added directly into the Registration 206 Request by using one of the "rsvd" bits. If a foreign or home agent 207 that does not support reverse tunnels receives a request with the 208 'T' bit set, the Registration Request fails. This results in a 209 registration denial (failure codes are specified in section 3.4). 211 Most home agents would not object to providing reverse tunnel 212 support, because they "SHOULD be able to decapsulate and further 213 deliver packets addressed to themselves, sent by a mobile node" 214 [1]. In the case of topologically correct reverse tunnels, the 215 packets are not sent by the mobile node as distinguished by its home 216 address. Rather, the outermost (encapsulating) IP source address on 217 such datagrams is the care-of address of the mobile node. 218 Nevertheless, home agents probably already support the required 219 decapsulation and further forwarding. 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type |S|B|D|M|G|V|T|-| Lifetime | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Home Address | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Home Agent | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Care-of Address | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Identification | 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Extensions ... 236 +-+-+-+-+-+-+-+- 238 The only change to the Registration Request packet is the additional 239 'T' bit: 241 T If the 'T' bit is set, the mobile node asks its home 242 agent to accept a reverse tunnel from the care-of 243 address. Lightweight mobile nodes ask the foreign 244 agent to reverse-tunnel its packets. 246 3.3. Reverse Tunnel Extension 248 The Reverse Tunnel Extension is used to further specify reverse 249 tunneling behavior. Currently, it is only possible to request the 250 encapsulating style of delivery, but future behavior may be 251 defined. The Reverse Tunnel Extension MUST NOT be included if the 252 'T' bit is not set in the Registration Request. 254 If this extension is absent, or if no style is explicitly requested, 255 the Lightweight Delivery is assumed. Besides the latter, currently 256 only the Encapsulating style is defined (section 5). 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Length |E| reserved | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Type 128 266 Length 2 268 E Encapsulating style of delivery. Encapsulation is done 269 according to what was negotiated for the forward tunnel 270 (i.e., IP in IP is assumed unless specified otherwise). 272 reserved Ignored upon reception. Must be set to zero when 273 transmitting. 275 3.4. New Registration Reply Codes 277 Foreign and home agent replies must convey if the reverse tunnel 278 request failed. Four new reply codes are defined. The use of codes 279 74 and 137 is preferred over code 70 for foreign agents and code 134 280 for home agents [1]: 282 Service denied by the foreign agent: 284 74 requested reverse tunnel unavailable 285 75 reverse tunnel is mandatory and 'T' bit not set 287 and 289 Service denied by the home agent: 291 137 requested reverse tunnel unavailable 292 138 reverse tunnel is mandatory and 'T' bit not set 294 4. Changes in Protocol Behavior 296 Reverse tunnels must be handled appropriately by the different 297 mobility entities. Differences in protocol behavior with respect to 298 the Mobile IP specification are: 300 4.1. Mobile Node Considerations 302 A mobile node sets the 'T' bit in its Registration Request to 303 petition a reverse tunnel. It may optionally also include a 304 Reverse Tunnel Extension. Possible outcomes are: 306 - The foreign agent returns a registration denial. Depending on 307 the reply code and following the error checking guidelines in 308 [1], the mobile node MAY try zeroing the 'T' bit, eliminating 309 the Reverse Tunnel Extension (if one was present), and issuing 310 a new registration. 312 - The home agent returns a registration denial. Depending on the 313 reply code and following the error checking guidelines in [1], 314 the mobile node MAY try zeroing the 'T' bit, eliminating the 315 Reverse Tunnel Extension (if one was present), and issuing a 316 new registration. 318 - The home agent returns a Registration Reply indicating that the 319 service will be provided. 321 In this last case, the mobile node has succeeded in establishing a 322 reverse tunnel between its care-of address and its home agent. If 323 the mobile node is operating with a co-located address, it SHOULD 324 encapsulate all outgoing data such that the destination address of 325 the outer header is the home agent. Not doing so does not 326 necessarily preclude data transmission, but it defeats the purpose 327 of the reverse tunnel. 329 If the care-of address belongs to a separate foreign agent, the 330 mobile node MUST employ whatever delivery style was requested 331 (lightweight or encapsulated) and proceed as specified in section 332 5. 334 4.2. Foreign Agent Considerations 336 A foreign agent that receives a Registration Request with the 'T' 337 bit set MAY either: 339 - Return a Registration Reply denying the request. Valid return 340 codes are 74 (requested reverse tunnel unavailable) or 70 341 (poorly formed request). Code 74 is preferred. 343 - Verify the packet according to [1] and then relay it to the 344 home agent. 346 Upon receipt of a Registration Reply that satisfies validity checks, 347 it MUST update its visitor list, including indication that this 348 mobile node has been granted a reverse tunnel and the delivery style 349 expected (section 5). 351 While this visitor list entry is in effect, the foreign agent MUST 352 process incoming traffic according to the delivery style, 353 encapsulate it and tunnel it from the care-of address to the home 354 agent's address. 356 4.3. Home Agent Considerations 358 A home agent that receives a Registration Request with the 'T' bit 359 set processes the packet as specified in the Mobile IP specification 360 [1]. As a result, it determines if it can accomodate the forward 361 tunnel request. As a last check, the home agent verifies that it can 362 support a reverse tunnel with the same configuration. 364 If it can, the home agent sends back a Registration Reply with code 365 0 or 1. A registration denial should send back code 137 (requested 366 reverse tunnel unavailable) or 134 (poorly formed Request). Code 367 137 is preferred. 369 After a successful registration, the home agent will receive 370 encapsulated packets addressed to it. For each such packet it MAY 371 search for a mobility binding whose care-of address is the source of 372 the outer header, and whose mobile node address is the source of the 373 inner header. 375 The home agent MUST decapsulate, recover the original packet, and 376 then forward it on behalf of its sender (the mobile node) to the 377 destination address (the correspondent host). 379 5. Mobile Node to Foreign Agent Delivery Styles 381 5.1. Lightweight Delivery Style 383 This delivery mechanism is very simple to implement, and uses small 384 (non-encapsulated) packets on the link between the mobile node and 385 the foreign agent (potentially a very slow link). However, it only 386 supports reverse-tunneling of unicast packets. 388 It is achieved by the mobile node's designating the foreign agent as 389 its default router Not doing so will not guarantee encapsulation of 390 all the mobile node's outgoing traffic, and defeats the purpose of 391 the reverse tunnel. The foreign agent must modify its forwarding 392 function to detect packets sent by the mobile node, and 393 re-encapsulate before forwarding. 395 Packet format received by the foreign agent (lightweight delivery): 397 Data Link fields: 398 Source Address = mobile node's MAC address 399 Destination Address = foreign agent's MAC address 400 IP fields: 401 Source Address = mobile node's home address 402 Destination Address = correspondent host's address 403 Upper Layer Protocol 405 Packet format forwarded by the foreign agent (lightweight delivery): 407 Data Link fields: 408 Source Address = foreign agent's MAC address 409 Destination Address = next hop router's MAC address 410 IP fields (encapsulating header): 411 Source Address = foreign agent's address 412 Destination Address = home agent's address 413 Protocol field: 4 (IP in IP) 414 IP fields (original header): 415 Source Address = mobile node's home address 416 Destination Address = correspondent host's address 417 Upper Layer Protocol 419 5.2. Encapsulating Delivery Style 421 This mechanism requires that the mobile node implement 422 encapsulation. The mobile node explicitly directs packets at the 423 foreign agent by designating it as the destination address in a new 424 outermost header. Mobile nodes that wish to send either broadcast 425 or multicast packets MUST use encapsulating delivery. 427 The foreign agent does not have to modify its forwarding function. 428 Rather, it receives the encapsulated packets and after verifying 429 that they were sent by the mobile node, recovers the inner packets, 430 re-encapsulates them and sends them to the home agent. 432 Packet format received by the foreign agent (encapsulated delivery): 434 Data Link fields: 435 Source Address = mobile node's MAC address 436 Destination Address = foreign agent's MAC address 437 IP fields (encapsulating header): 438 Source Address = mobile node's address 439 Destination Address = foreign agent's address 440 Protocol field: 4 (IP in IP) 441 IP fields (original header): 442 Source Address = mobile node's home address 443 Destination Address = correspondent host's address 444 Upper Layer Protocol 446 Packet format forwarded by the foreign agent (encapsulated delivery): 448 Data Link fields: 449 Source Address = foreign agent's MAC address 450 Destination Address = next hop router's MAC address 451 IP fields (encapsulating header): 452 Source Address = foreign agent's address 453 Destination Address = home agent's address 454 Protocol field: 4 (IP in IP) 455 IP fields (original header): 456 Source Address = mobile node's home address 457 Destination Address = correspondent host's address 458 Upper Layer Protocol 460 5.3. Support for Broadcast and Multicast Datagrams 462 If a mobile node is operating with a co-located address, broadcast 463 and multicast datagrams are handled according to Sections 4.3 and 464 4.4 of the Mobile IP specification [1]. Light-weight mobile nodes 465 MAY have their broadcast and multicast datagrams reverse-tunneled by 466 the foreign agent. However, this requires the use of the the 467 encapulating delivery style. 469 This delivers the datagram only to the foreign agent. The latter 470 decapsulates it and then processes it as any other packet from the 471 mobile node, namely, by reverse tunneling it to the home agent. 473 6. Security Considerations 475 The extensions outlined in this document are subject to the security 476 considerations outlined in the Mobile IP specification [1]. 477 Essentialy, creation of both forward and reverse tunnels involves an 478 authentication procedure, which reduces the risk for attack. 480 However, once the tunnel is set up, a malicious user could hijack it 481 to inject packets into the network. Reverse tunnels might exacerbate 482 this problem, because upon reaching the tunnel exit point packets 483 are forwarded beyond the local network. This concern is also present 484 in the Mobile IP specification, as it already dictates the use of 485 reverse tunnels for certain applications. 487 There has been some concern regarding the long-term effectiveness of 488 reverse-tunneling in the presence of ingress filtering. The 489 conjecture is that network administrators will target 490 reverse-tunneled packets (IP in IP encapsulated packets) for 491 filtering. The ingress filtering recommendation spells out why this 492 is not the case [8]: 494 Tracking the source of an attack is simplified when the source is 495 more likely to be "valid." 497 7. Acknowledgements 499 The encapsulating style of delivery was proposed by Charlie Perkins. 501 References 503 [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996. 505 [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October 506 1996. 508 [3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks 509 and Hijacked Terminal Connections", CA-95:01, January 1995. 510 Available via anonymous ftp from info.cert.org in 511 /pub/cert_advisories. 513 [4] D. Johnson and C. Perkins. Route Optimization in Mobile IP -- 514 work in progress, draft-ietf-mobileip-optim-05.txt, November 515 1996. 517 [5] Manuel Rodriguez, private communication, August 1995. 519 [6] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. 521 [7] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, 522 August 1995. 524 [8] P. Ferguson and D. Senie. Network Ingress Filtering: Defending 525 Against IP Source Address Spoofing -- work in progress, 526 draft-ferguson-ingress-filtering-01.txt, February 1996 528 Author's Address 530 Gabriel E. Montenegro 531 Sun Microsystems, Inc. 532 2550 Garcia Avenue 533 Mailstop UMPK 15-214 534 Mountain View, California 94043-1100 536 Tel: (415)786-6288 537 Fax: (415)786-6445 539 gab@eng.sun.com