fwiw the rfc editor will do a scrub of the text. thanks
joel On 12/15/13, 7:08 AM, Carlos Pignataro (cpignata) wrote: > Donald, > > Thank you for your comments, please see inline. > > On Dec 14, 2013, at 8:29 PM, Smith, Donald <[email protected]> > wrote: > >> Shouldn't this be environment not environments ? >> 1.... >> Additionally, it outlines what a network operator might do in a typical >> enterprise or Service Provider environments. >> > > Seems like something the RFC Editor would catch if it is incorrect. > > "Environment" in singular potentially 'sounds' better; however, your proposal > seems incorrect without an "a" before "Service Provider". In any case -- to > me, if the sentence intends to convey "in a typical enterprise environment or > a typical SP environment" (i.e., "environment" applying to both), then "in a > typical enterprise or SP environments" should be correct as-is. > > That said, we could make a note and ask the RFC Editor. Thank you. > >> >> 1.2. Operational Focus >> >> All of the recommendations in this document have been made in an >> effort to optimise for operational community consensus, as best the >> editors have been able to determine that. >> >> optimize not optimiSe and that isn't English. That is it isn't a complete >> thought/sentence that I can understand anyways? > > I can say the same thing about your comment :-) What exactly is not English? > It is not clear :-) > > We can make an RFC Editor note to replace "optimise" with "optimize". Thank > you. > > I think "optimize" is American and "optimise" is British, but the dictionary > recognizes (and recognises) both. > >> >> Technical against the draft not just the iesg additions!! >> I swear I said this before but ISPs and others are going to want at least >> one more option (possibly two) here. >> >> 4.3.5. Advice >> >> Routers, security gateways, and firewalls SHOULD implement an option- >> specific configuration knob whether packets with this option are dropped, >> packets with this IP option are forwarded as if they did not contain this IP >> option, or packets with this option are processed and forwarded as per >> [RFC0791]. >> >> >> Does drop that imply silently drop? (I think it does as opposed to deny >> where an icmp error should be sent). Shouldn't there be a deny with some >> icmp code being sent saying the packet contained unsupported options? Either >> 3,5 (source router failed for SSRR or LSRR) or 3,9 (admin prohibited) for >> other options? >> > > To prevent misuse of CPU resources, this does not send an ICMP. Similar to > 4.11.3. > > Additionally, both your proposals would be incorrect. ICMP 3/5 is incorrect > since it is not a failure of the source route, ICMP 3/9 as well as ICMP3/10 > are also incorrect, because what is admin prohibited is neither the network > nor the host. There is no ICMP type that says "option admin prohibited", and > we do not want to create one. > >> Forwarded as if they did not contain ... is commonly called ignored or not >> processed. I like spelling it out but lets give it a short version name for >> router heads/configs. >> > > Yes, we use "ignore" throughout. > >> >> Next we SHOULD permit a "clear" where by the device removes the unwanted >> options and repads/rechecksums the packet if it could potentially be >> dangerous to an "inner" device. >> > > Do you know of any device that supports that? This is a BCP for current > practices. > >> This: >> Please note that treating packets with LSRR as if they did not >> contain this option can result in such packets being sent to a >> different device that the initially intended destination. With >> appropriate ingress filtering this should not open an attack vector >> into the infrastructure. Nonetheless, it could result in traffic >> that would never reach the initially intended destination. Dropping >> these packets prevents unnecessary network traffic, and does not make >> end-to-end communication any worse. >> >> >> Should be this: >> Please note that treating packets with LSRR as if they did not >> contain this option can result in such packets being sent to a >> different device THAN the initially intended destination. With >> appropriate ingress filtering this should not open an attack vector >> into the infrastructure. Nonetheless, it could result in traffic >> that would never reach the initially intended destination. Dropping >> these packets prevents unnecessary network traffic, and does not make >> end-to-end communication any worse. >> > > OK, we can have an RFC Editor note to replace "that" with "than". > >> It also isn't true:( >> >> Consider a LSRR A-B-C-D >> If A received it and ignores it (including the record route part) and hands >> it off to something next to A (1 hop away) that device could hand it back to >> A (since it should be in the RR path but isn't) causing a loop that bounces >> between A and it neighbor until the ttl expires right? > > Wrong. > > If A ignores the option, it means if performs forwarding based on the > destination IP address in the IP Header. If it sends it to B, B does the same > IP header address destination-based forwarding, why would it send it to A? I > mean, of course unless there is a routing loop regardless of the presence of > LSRR... > > The only reason for that paragraph is that strictly, based on the LSRR > presence, the packet could be destined to a different end device than the one > on the IP address destination, based on the pointer. In other words, the ip > address points to an intermediate device. Now, that does not create loops. > >> So not only did it not arrive at the destination it also could be used to >> ddos A. >> > > No. See above. > >> 4.4.5 >> >> different device that >> >> should be: >> different device than >> >> >> >> > > Yes. > > Net-net: "optimise" -> "optimize", and "that" -> "than". > > Thank you, > > Carlos. > >> >> >> >> >> >> >> >> >> >> >> >> >> (coffee != sleep) & (!coffee == sleep) >> [email protected] >> >> >> >> From: OPSEC [[email protected]] on behalf of joel jaeggli >> [[email protected]] >> Sent: Wednesday, December 11, 2013 10:28 AM >> To: [email protected]; [email protected] >> Subject: [OPSEC] post iesg final version of >> draft-ietf-opsec-ip-options-filtering (07) >> >> >> you can refer to the diff here. >> >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsec-ip-options-filtering-07.txt >> >> if anyone has issue with any of the changes made to address iesg review >> or post-last-call change please squawk soon. >> >> thanks >> joel >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
