Re: [secdir] Secdir review of draft-baker-ietf-core-03.txt

Fred Baker <> Sat, 21 November 2009 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F0D83A686C; Sat, 21 Nov 2009 05:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.419
X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jw0AWSNw-iax; Sat, 21 Nov 2009 05:08:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CDCE03A682E; Sat, 21 Nov 2009 05:08:57 -0800 (PST)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIEAMN0B0tAaHte/2dsb2JhbACCIi65cZddhDwEgXCBEQ
X-IronPort-AV: E=Sophos; i="4.47,264,1257120000"; d="scan'208,217"; a="107575571"
Received: from ([]) by with ESMTP; 21 Nov 2009 13:08:53 +0000
Received: from [] ( []) by (8.13.8/8.14.3) with ESMTP id nALD8p5p024076; Sat, 21 Nov 2009 13:08:52 GMT
Message-Id: <>
From: Fred Baker <>
To: Charlie Kaufman <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary=Apple-Mail-86--818626926
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sat, 21 Nov 2009 22:08:50 +0900
References: <>
X-Mailer: Apple Mail (2.936)
Cc: "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-baker-ietf-core-03.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Nov 2009 13:08:59 -0000

Thanks. I'll review your comments next week when I'm at home :-)

On Nov 21, 2009, at 1:41 PM, Charlie Kaufman wrote:

> I am reviewing this document as part of the security directorate's  
> ongoing effort to review all IETF documents being processed by the  
> IESG.  These comments were written primarily for the benefit of the  
> security area directors.  Others should treat these comments just  
> like any other last call comments. Feel free to forward to any  
> appropriate forum.
> This document (proposed as an Informational RFC) summarizes the core  
> protocols on which the Internet operates. It is specifically  
> targeted at NIST in the context of the Smart Grid discussion. They  
> are looking to “profile” a subset of the Internet Protocol Suite.  
> Since the audience for this review is security focused, I’ll talk  
> about security first. But since I read it all, I’ll include comments  
> on the rest too. I would encourage others to read the document. It’s  
> both informative and could generate a lively discussion about what  
> constitutes “the core”.
> As a truly informational document, this document has no security  
> implications, though it does talk about security. It considers  
> IPsec, TLS, and S/MIME to be the core security protocols. I would  
> consider adding DNSSEC to that list, and possibly removing S/MIME,  
> but these three are certainly a reasonable place to start.
> Section 3.1 attempts to explain why it’s natural for IPsec and TLS  
> to both exist, and reminded me how much each has encroached onto the  
> territory of the other making that task more difficult. I believe  
> that the original distinction was that IPsec was designed to be  
> implemented in operating systems or networking infrastructure in a  
> way that was transparent to applications, while SSL was designed to  
> be implemented in applications in a way that was transparent to  
> operating systems and networking infrastructure. That’s not a bits  
> on the wire distinction, but I believe all the other differences  
> derive from that. But TLS has now been extended to protect datagrams  
> and IPsec to authenticate users with SecurID cards. I don’t know  
> which is the more natural fit for Smart Grid, but I doubt it’s both.
> Comments on the whole document:
> Section 1 para 3: re: picking a subset of protocols rather than  
> protocol subsets. This makes sense for “old” protocols, like TCP,  
> that have few options. It doesn’t for “new” protocols, like PKIX,  
> which allow variation without end.
> Section The Internet Layer here is what you called the  
> Network Layer on the previous page (I think). Fragmentation and  
> reassembly is only part of this layer any more if you hold your head  
> just right. I’m not sure “identifying” a datagram’s source and  
> destination is properly the roll of this layer. “Finding” the  
> destination is more like it. This section describes the part of the  
> IP layer implemented by endnodes. Most of IP is implemented (today)  
> in intermediate nodes. Would OSPF be a core protocol, or do you  
> assume these systems run atop an existing infrastructure?
> Section 2.2.1: Physical security: It’s worth mentioning that many  
> systems assume physical security within some subnet (like a machine  
> room or a corporate intranet) and reflect that in believing that  
> source and destination IP addresses are authentic if they are both  
> in a controlled range. One might question whether this is wise, but  
> it is certainly common. Protocols often reflect assumptions about  
> physical failures and attacks in the timeout/retry parameters they  
> choose.
> Section 2.2.2: The last paragraph seems to have fallen into this  
> document from somewhere else. Does it belong elsewhere?
> Section 2.3: DNS seems like a critical piece of making the Internet  
> work. There might be applications that could live without it, but  
> not many.
> Section 2.3.1: DNS also supports limited slow mobility. A service  
> can move and change IP address if everyone references it by DNS name.
> Section 3.1.2: It’s misleading to say that IPsec implemented between  
> the routing and transport layer. That’s true in transport mode, but  
> in tunnel mode there is an IP header before and after the IPsec  
> header (putting it in the middle of routing).
> Section 3.1.2: In the RFC list RFC4304 is the right RFC to reference  
> but it is not ISAKMP. RFC4309 specifies AES CCM mode, which I  
> believe is not the most commonly used cryptographic algorithm.
> Section 3.1.4: I’d be surprised if S/MIME was originally an  
> extension to SMTP. Even when S/MIME was PEM, it was largely  
> transport independent (and designed to pass over X.400, which was a  
> contender in those days). S/MIME – and more generally CMS – is not  
> really a networking protocol at all. It is designed to protect data  
> at rest. I can take a CMS protected file and send the pile of bits  
> to you by floppy disk or paper tape. Years later, if you can still  
> read the media, you can still process it. It’s a tough call whether  
> it is an Internet Core Protocol. It’s certainly an important IETF  
> protocol.
> Section 3.2: “the IPv6 space” -> “the size of the IPv6 address space”
> Section 3.2: “in the near term.” -> “in the near term if  
> interoperability with existing IPv4-only systems is important.”
> Section It’s worth noting that IPv4 addresses are typically  
> administratively assigned in blocks, which then get subdivided, and  
> that they are commonly handed out individually to client nodes using  
> DHCP but that servers typically need permanent IPv4 addresses so  
> that other nodes can find them in DNS.
> Section Avoid a common confusion by explaining that  
> reliable in this case means that retries are automatic and that  
> failures are reliably detected. Reliable Multicast can’t get the  
> data there if the network is broken.
> Section IPv6 also hands out addresses administratively in  
> blocks which are then subdivided. Autoconfiguration is only  
> different from DHCP in that you’re “guaranteed” not to run out.
> Section Mention that addresses are hierarchical when handed  
> out administratively in order to keep routing tables from exploding  
> in size.
> Between section 3.2.3 and 3.3: This would be a good place to remind  
> people of the “hourglass”: many protocols above, many below, but a  
> single IP in the middle. (Well IPv4 and IPv6, but that’s “temporary”).
> Section 3.3.1, para 1: I would claim that UDP is a perfectly valid  
> transport protocol. It only appears not to be because it is the  
> native mode of IP and therefore seems natural. Running over X.25,  
> TCP would seem like the null protocol and UDP would be interesting  
> and novel.
> Section 3.3.1, para 2: UDP has problems because it does not play  
> well with others in terms of congestion backoff. Does it have  
> problems other than that?
> Section 3.4.1, para 1, line 6: “all” -> “allow”
> Middle of page 22: “address/aport” -> “address/port”