Early Review of draft-baker-ietf-core-
review-baker-ietf-core-secdir-early-kaufman-2009-11-28-00

Request Review of draft-baker-ietf-core
Requested rev. no specific revision (document currently at 15)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2011-03-01
Requested 2009-10-08
Draft last updated 2009-11-28
Completed reviews Secdir Early review of -?? by Charlie Kaufman
Tsvdir Last Call review of -?? by Rolf Winter
Secdir Last Call review of -?? by Charlie Kaufman
Assignment Reviewer Charlie Kaufman
State Completed
Review review-baker-ietf-core-secdir-early-kaufman-2009-11-28
Review completed: 2009-11-28

Review
review-baker-ietf-core-secdir-early-kaufman-2009-11-28

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 2.1.3.1: 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 3.2.1.1: 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 3.2.1.3: 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 3.2.2.1: 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 3.2.2.2: 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”