[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MUSTs

 "dh" == Dan Hollis <goemon@anime.net> writes:

dh> On Sat, 2 Aug 2003, George Jones wrote:
>> IF I recall correctly, the one question that was raised was "what
>> part of the RFCs" (MUST/SHOULD/MAY...) does this requirement require ?
>> My basic response would be "MUSTs" + compliance with the RFC on any
>> of the SHOULDs/MAYs implemented.
>> Thoughts ?  Rewording suggestions ?

No, that makes sense.  If you MUST follow RFC 12345, and RFC 12345
says you SHOULD do something, then you MUST take their recommendation
of SHOULD.

dh> IIRC there are a couple RFCs where several MUSTs or SHOULDs are 
dh> detrimental to network security (as it currently stands today).

dh> We should list specific exceptions, where it would be detrimental to 
dh> security policy. IIRC several of them applied to ICMP messages.

dh> Isnt there an RFC stating new policies in regards to eg broadcast pings? 
dh> Eg MUST NOT reply...

This requirement was born in our test lab when we recieved a DSLAM
from a new vendor.  Nmap returned 65535 ports as "LISTENING", because
any SYN packet addressed to the craft interface recieved a SYN/ACK.
If it was TCP/23, SYN, SYN/ACK, ACK, connection.  If it was a random
port, SYN, SYN/ACK, ACK, RST.  The vendor had taken it upon themselves
to rewrite TCP.

We'd seen other, vaguely similar behavior before, but this was the
straw that broke the camel's back.

IMHO, we should require the vendors to provide full RFC compliance in
all cases.  At one point in history, Cisco's 'no ip directed
broadcast' was in violation of one or more RFCs.  That was fine, the
device COULD comply, as long as you configured it properly.  Many
times (stealting, broadcast ping, etc), breaking RFCs is a good idea,
but the device must be capable of playing nicely with others.

The requirement is for the device to be able to be configured such
that it does comply with all relevant RFCs, not that it should be
operated in that condition.

ericb