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: Message signed with OpenPGP using GPGMail
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
