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.
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?
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?
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.
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.
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.
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? So not only did it not
arrive at the destination it also could be used to ddos A.
4.4.5
different device that
should be:
different device than
(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
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
