[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: http://www.ietf.org/internet-drafts/draft-morrow-filter-caps-00.txt
Chris, George other opsec team mates.
My comments marked with DJS>
Overall comments first inline comments original text followed by my comments.
DJS>All references to filtering appear to be
DJS>"to" the device there should be
DJS>some "through" device filtering.
DJS>Several items imply through filtering.
2.1.7 Ability to Filter To the Device - Ability to Filter
Protocols . . . . . . . . . . . . . . . . . . . . . . 10
2.1.8 Ability to Filter To the Device - Ability to Filter
Addresses . . . . . . . . . . . . . . . . . . . . . . 11
2.1.9 Ability to Filter To the Device - Ability to Filter
Ports . . . . . . . . . . . . . . . . . . . . . . 11
DJS> 2.1.10 Ability to Filter To the Device - Ability to Filter
DJS> Protocol Header Fields . . . . . . . . . . . . . . . . 11
DJS> 2.1.11 and 2.1.16 appear to be the same feature. Both address counter
DJS> accuraty.
2.1.16 Ability to Filter To the Device - Filter Counters
are Accurate . . . . . . . . . . . . . . . . . . . . 16
1.1 Threat Model
Networks must have the ability to place mitigation in order to limit
DJS>Networks must have the ability to place mitigation anywhere in the
DJS>providers network in order to limit
these threats. These mitigation steps could include routing updates,
traffic filters, and routing filters. It is possible that the
mitigation steps might have to affect transit traffic as well as
traffic destined to the device on which the mitigation steps are
activated.
The scope of the threat includes simply denying services to an
individual customer on one side of the scale to exploiting a newly
discovered protocol vulnerability which affects the entire provider
DJS>discovered vulnerability which affects the entire provider
core. The obvious risk to the business requires mitigation
capabilities which can span this range of threats.
2.1.1 Ability to Filter Traffic on All Interfaces
Capability.
The device provides a means to filter IP packets on any interface
implementing IP.
DJS>Some inline devices or cards may not have an IP. We still want to be able
DJS> filter on them.
Considerations.
DJS> Some filtering implementations are Line Card based.
DJS> or interface based. So 1 interface may be able to filter
DJS> another in the same system may not.
DJS> For example engine 4 vs engine 3 line cards.
2.1.2 Ability to Filter Traffic To the Device
Current Implementations.
Many devices currently implement access control lists or filters
that allow filtering based on protocol and/or source/destination
address and or source/destination port and allow these filters to
DJS> address and/or source/destination port and allow these filters to
be applied to services offered by the device.
DJS> be applied to services offered on the device.
Examples of this might include filters that permit only BGP from
peers and SNMP and SSH from an authorized management segment and
DJS> peers and SNMP and SSH from an authorized management network and
Considerations.
DJS> Filtering non-connection oriented protocols such as udp
DJS> ON a system is only partially effective since source
DJS> based spoofing of the correct management network is still an option.
2.1.3 Ability to Filter Traffic To the Device - Minimal Performance
Degradation
Capability.
The filtering of traffic destined to interfaces on the device,
including the loopback interface, should not degrade performance
significantly.
DJS> should not degrade preformance to the point that legitimate
DJS> managagement and control plane traffic gets dropped.
2.1.5 Ability to Filter To the Device - Log Filter Actions
DJS> * Timestamp
2.1.6 Ability to Filter To the Device - Specify Log Granularity
Current Implementations.
If a filter is defined that has several rules, and one of the
rules denies telnet (tcp/23) connections, then it should be
possible to specify that only matches on the rule that denies
telnet should generate a log message.
DJS> and per rule classifications such as priority and facility ala syslog.
2.1.7 Ability to Filter To the Device - Ability to Filter Protocols
Considerations.
DJS> Possible unknown sideeffects such as blocking a protocol may affect
DJS> some unknown applicaton that uses that protocol number.
2.1.9 Ability to Filter To the Device - Ability to Filter Protocol
Header Fields
Capability.
The filtering mechanism supports filtering based on the value(s)
of any portion of the protocol headers for IP, ICMP, UDP and TCP.
It supports filtering of all other protocols supported at layer 3
and 4. It supports filtering based on the headers of higher level
protocols. It is possible to specify fields by name (e.g.,
"protocol = ICMP") rather than bit- offset/length/numeric value
(e.g., 72:8 = 1).
DJS> Would an off system macro language be acceptable here? Something like
make?
2.1.10 Ability to Filter To the Device - Ability to Filter Inbound and
Outbound
Considerations.
DJS> Higher grainularity implies greater complexity which implies higher
DJS> resource usage (cpu, memory ...)
2.1.11 Ability to Filter To the device - Ability to Accurately Count Filter
hits.
Considerations
DJS> Since this number could be changing rapidly and given that it is more
important to filter the traffic and forward the good traffic some reasonable %
might be in order here.2.1.11 Ability to Filter To the device - Ability to
Accurately Count Filter hits.
Considerations
DJS> Since this number could be changing rapidly and given that it is more
DJS> important to filter the traffic and forward the good traffic some reasonable %
DJS> might be in order here.
donald.smith@qwest.com giac
-----Original Message-----
From: owner-opsec@psg.com on behalf of George Jones
Sent: Tue 2/15/2005 1:13 PM
To: opsec@ops.ietf.org
Subject: http://www.ietf.org/internet-drafts/draft-morrow-filter-caps-00.txt
http://www.ietf.org/internet-drafts/draft-morrow-filter-caps-00.txt