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

[Fred Baker <[e-mail]>]

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 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”