Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Cyber Security Awreness Month - Day 9 - Request for Comment (RFC)

Published: 2012-10-09
Last Updated: 2012-10-09 13:52:30 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

The Internet Engineering Task Force (IETF) is the main standard body for Internet related protocols. As far as standard bodies go, the IETF is probably the most open. Standards are discussed on mailing lists, and all you need to do is sign up for a mailing list and chime in, or attend one of the IETF meetings or both. There is no "membership" and standards usually require aconsensus. 

The RFC Process

RFCs are not only published by the IETF, but the Internet Architecture Board (IAB) and Internet Engineering Steering Group (IESG).  Not all RFCs are "standards". Some just document best practices or just informational (for example RFC1796: "Not all RFCs are Standards"). There are three distinct sub-series: Standards (STD), Best Current Practice (BCP) and Informational (FYI).

The RFC process itself is regulated by RFCs. RFCs start out as Internet Drafts. These drafts have a limited lifetime (default is 6 months) and are discarded unless they are selected to become an RFC by the IESG. 

Once an RFC is published, it's content can no longer be changed. Once in a while you will see erratas that are added to RFCs. But for the most part, to update an RFC, a new RFC needs to be published. When researching RFCs, it is VERY important to make sure it hasn't been updated by a newer RFC (I prefer the listing at http://tools.ietf.org/html/ as it links to updates)

There is no enforcement of RFCs, other then peer pressure. For the most part, if you want stuff to work, you better follow RFCs. Until about a week ago, one of the expressions of the peer pressure aspect of the RFC system was rfc-ignorant.org .  The site listed networks that choose not to obey some RFCs, in particular related to spam and abuse reporting. 

RFCs and Security

All RFCs should have a security sections. It will summarize any security impact the particular RFC may have. In addition, there are a good number of RFCs that deal with security issues.  I recommend taking a look at new RFCs regularly. Internet standards are very dynamic and assumptions you make based on old standards can be dangerous, or you are not taking advantage of some of the newer features.

IETF also publishes a list of security related RFCs here: http://www.apps.ietf.org/rfc/seclist.html

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

0 comment(s)
Diary Archives