idnits 2.17.1 draft-lohsen-ip-burrito-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 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 340. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 308), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC-791]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- 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: 'RFC-791' is mentioned on line 103, but not defined == Unused Reference: 'RFC791' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 284, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Schulze 3 Internet-Draft Matthew.Schulze@mapics.com 4 April 1, 2005 W. Lohsen 5 William.Lohsen@GTRI.gatech.edu 7 IP over Burrito Carriers 8 draft-lohsen-ip-burrito-00 10 Status of this Memo 12 This memo defines an Experimental Protocol for the Internet 13 community. It does not specify an Internet standard of any kind. 14 Discussion and suggestions for improvement are requested. 15 Distribution of this memo is unlimited. 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 and any of which I become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire in October, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). All Rights Reserved. 44 Abstract 46 IP over Burrito Carriers describes an experimental method for the 47 creation of edible data packets. This standard is intended to be 48 implemented in metropolitan area networks due to the preexisting 49 burrito delivery infrastructure. While currently only flour tortillas 50 have been found acceptable for encapsulating the data contained in 51 the packet, tests are underway to determine the viability of using 52 corn tortillas. One must be wary of disreputable IP over Burrito 53 service providers as packet corruption and bad data handling can 54 result in damage to the receiving unit and may result in an extremely 55 messy packet rejection. Conveniently, there is a rating system 56 already in place. While the rating by the health department doesn't 57 ensure proper data encapsulation, it does allow the end user to 58 determine if the service provider's quality to cost ratio is 59 adequate. This is an experimental standard, not a recommended 60 standard. 62 Introduction 64 In today's wireless hotspot, WAP enabled, WiFi zoned world of dining 65 there exists a discrimination against diners who prefer to eat 66 outside the established confines of the restaurant. The IP over 67 Burrito standard was developed to create an edible solution to the 68 growing rift in the availability of free internet access between 69 sit-down and delivery/carry out diners. While considerable research 70 has yet to be performed on the IP over Burrito standard, multiple 71 simulations in a controlled environment have proven to be both 72 successful and filling. Some concerns that must be addressed 73 in the future include the ability of the hosts buffer to 74 accommodate a large number of packets while they are processed. Also 75 the fact that a buffer overflow would cause a catastrophic system 76 failure resulting in a purging of all previously processed datagrams 77 is of major concern. Currently datagrams are encapsulated in a flour 78 tortilla. Future projects will determine the viability of using corn 79 tortillas but for now the standard requires the use of a flour 80 tortilla for all datagram encapsulation. 82 Packet Format 84 Packets will follow the standard Internet Header Format [RFC-791] 85 (Figure 1). Each field (Figure 1) has been sublimated with a tangible 86 equivalent (Figure 2) to binary representation that is both tasty and 87 filling. 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 |Version| IHL |Type of Service| Total Length | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | Identification |Flags| Fragment Offset | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | Time to Live | Protocol | Header Checksum | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | Source Address | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Destination Address | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Data | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 The Internet Header Format [RFC-791] 105 Figure 1. 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 |Obvious| Onion | Jalapenos | Physical Length (mm) | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Number Written on Foil |Bean Type| Number of Beans | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Given Delivery Time | Guacamole | Receipt | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Lettuce | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Rice | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Beef | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 The Burrito Internet Header Format 123 Figure 2. 125 Version: Obvious 127 The Version field is indicated by the obvious. It is a burrito. 128 As the IP over Burrito standard is designed to work solely 129 with modern equipment, it supports only IPv4 packets. 131 IHL: Onion 133 Internet Header Length is specified by the number of onions placed 134 in the burrito. 136 Type of Service: Jalapenos 138 The 8 bits of this header are specified by 8 jalapeno slices. A 139 half slice indicates a zero and a whole slice indicates a one. 141 Total Length: Physical Burrito Length 143 The length of the burrito in centimeters multiplied by 4096 gives 144 the total length of the datagram, in octets. 146 Identification: Number written on foil wrapper. 148 Flags: Type of Beans 150 Black Beans = Don't Fragment 151 Red Beans = Fragment 152 Pinto Beans = Last Fragment 153 Kidney Beans = More Fragments 155 Fragment Offset: Total Number of Beans. 157 Time to Live: Specified by source host in minutes. 159 Commonly in the range of 35-45 minutes, given traffic conditions. 161 Protocol: Guacamole 163 The chunkiness, quality, and amount of Guacamole determine this 164 data. 166 Header Checksum: Receipt 168 The data on the receipt should match the specifications of the 169 burrito datagram. 171 Source Address: Lettuce 173 Given the size of this field it is necessary to break it down 174 into subsections. The lettuce is placed in 4 discrete groups. 175 Also, the lettuce is colored with food coloring to be either 176 red, green, or blue. Red lettuce indicates the most significant 177 digit, green the middle digit, and blue the least significant 178 digit. Thus limiting the amount of lettuce on the burrito to a 179 manageable level in respect to determining the data and fitting 180 in the tortilla. 182 Destination Address: Rice 184 Given the size of this field it is necessary to break it down 185 into subsections. The rice is placed in 4 discrete groups. 186 Also, the rice is colored with food coloring to be either 187 red, green, or blue. Red rice indicates the most significant 188 digit, green the middle digit, and blue the least significant 189 digit. Thus limiting the amount of rice on the burrito to a 190 manageable level in respect to determining the data and fitting 191 in the tortilla. 193 Data: Beef 195 The data will be transmitted in a beef representation of 196 hexadecimal. Each beef cluster will be counted as a decimal 197 representation of a hexadecimal digit. Each beef field will be 198 separated by a slice of chicken. There will be a maximum of 15 199 chunks of beef and a minimum of 0 chunks of beef per unit chicken. 200 Approximately 16 bytes of data can be stored per burrito packet. 202 Packet Routing 204 Should a node become damaged or congested (i.e. traffic jam, 205 construction, etc) and be unable to accommodate Burrito encapsulated 206 packets in a timely fashion then the packet will be routed by the 207 delivery boy around any obstructions in an attempt to make a 208 delivery inside of the packets given TTL. 210 Security Considerations 212 The IP over Burrito service can be considered secure for almost any 213 non-tactical use. Before transmission, the data contents of the 214 packet are sterilized, killing most viruses that might be transmitted 215 via the packet. Unfortunately, due to the nature of the packet, this 216 uninfected state is only temporary. Unlike the current IP 217 transmission standard, packets created by the IP over Burrito Carrier 218 service are vulnerable to infection during transmission. Infected 219 packets will usually be detected two to four hours after the packet 220 is destroyed. 222 As every packet is encapsulated in an opaque wrapper, the data inside 223 the packet is impossible to access via standard packet sniffing 224 procedures. Attempts to breach the encapsulation of the package in 225 transit will likely cause permanent damage to the encapsulation, 226 thereby signaling to the original recipients of the packet that data 227 interception was attempted. Re-encapsulation of the original data is 228 impossible, as the packet data is tightly integrated with the 229 encapsulation. Due to the long delay between packet transmission and 230 packet reception, however, there is sufficient time for a third party 231 to duplicate the packet data and forward it to the original 232 recipient. The detection of this interception is likely only if the 233 recipient should follow the standard packet disposal process and be 234 well acquainted with the peculiarities of packets created by a given 235 server. 237 Packet transportation uses a highly advanced algorithm to prevent 238 damage to the packet and to prevent its reception by third parties. 239 As the packet transportation system is highly vulnerable to social 240 engineering, however, the use of encryption is recommended for the 241 transmission of any secure data. 243 Although the packets decay naturally over time, the slow rate of 244 natural packet decay will likely make user-induced destruction 245 mandatory to prevent third parties from examining the packet data 246 after the packet has been received. Unfortunately, the packet 247 delivery system works poorly in a tactical environment, as the packet 248 can be easily waylaid by hostile forces. 250 Due to the extended time that packet creation requires, servers will 251 be highly vulnerable to message flooding. and responses will be 252 delayed greatly; however, the likeliness of a IP over Burrito DOS 253 attack can be considered negligible, as the clients are charged for 254 each packet that the server sends to them. 256 Of more concern is the extended time that packet processing requires 257 on the receiving hosts end. Should a host attempt to process more 258 than 5 packets a in a one hour period a buffer overflow could occur 259 and data might be lost, or worse: it could be disseminated in a 260 disorganized and partially processed state all over any nearby 261 objects. This could result in damage to secondary systems and the 262 server storage facility. Unfortunately a buffer overflow on one host 263 can cause hosts in the immediate vicinity to suffer similar buffer 264 overflows. 266 Also a matter of great concern is the ability of viruses to spread 267 by IP over Burrito. Should the server or packet itself be infected 268 then infection of the host is highly likely. When dealing with an 269 unknown server it is advisable to carefully examine the packet for 270 any sign of damage or infection (i.e. rotten smell, slick covering 271 to the meat, etc). 273 IANA Considerations 274 This document has no actions for IANA. 276 Normative References 278 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 279 1981. 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 285 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 286 October 1998. 288 Authors' Addresses 290 Matthew Schulze 291 Paragon Systems International 292 1000 Windward Concourse Parkway, suite 140 293 Alpharetta, GA, 30005 295 EMail: Matthew.Schulze@mapics.com 297 William Lohsen 298 Georgia Tech Research Institute 299 347 Ferst Drive 300 Atlanta, Georgia 30332-0821 302 EMail: William.Lohsen@GTRI.gatech.edu 304 Full Copyright Statement 306 Copyright (C) The Internet Society (2005). This document is subject 307 to the rights, licenses and restrictions contained in BCP 78, and 308 except as set forth therein, the authors retain all their rights. 310 This document and the information contained herein are provided on 311 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 312 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 313 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 314 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 315 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 316 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 318 Disclaimer of Validity 320 The IETF takes no position regarding the validity or scope of any 321 Intellectual Property Rights or other rights that might be claimed 322 to pertain to the implementation or use of the technology 323 described in this document or the extent to which any license 324 under such rights might or might not be available; nor does it 325 represent that it has made any independent effort to identify any 326 such rights. Information on the procedures with respect to rights 327 in RFC documents can be found in BCP 78 and BCP 79. 329 Copies of IPR disclosures made to the IETF Secretariat and any 330 assurances of licenses to be made available, or the result of an 331 attempt made to obtain a general license or permission for the use 332 of such proprietary rights by implementers or users of this 333 specification can be obtained from the IETF on-line IPR repository 334 at http://www.ietf.org/ipr. 336 The IETF invites any interested party to bring to its attention 337 any copyrights, patents or patent applications, or other 338 proprietary rights that may cover technology that may be required 339 to implement this standard. Please address the information to the 340 IETF at ietf-ipr@ietf.org.