[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on latest IPSP drafts
(I've been lurking on this list for the last year, but haven't had time to
contribute until now. I hope to be more active in the future. I also hope
these comments don't duplicate discussions at this week's IETF, which I was not
able to attend.)
These are comments on the 5 IPSP drafts that were posted a couple of weeks
ago. I've reviewed and commented on these as a whole.
- I suggest that there should be a discussion of the impact of IP
fragmentation. In particular: (a) performance is affected since IP packets
that already equal the MTU size will overflow with the addition of the AH or
ESP data; (b) I think there should be an implementation note that the sender of
an IPSP packet should make sure to put it through the fragmentation process,
and the destination of an IPSP packet must reassemble it before processing the
AH header or ESP payload.
- The definition of "authentication" and "integrity" on page 1 of the
architecture draft implies that the former is a superset of the latter. This
is inconsistent with the usual terminology, which treats these as distinct
concepts.
- The architecture draft, and some of the others, refer to a number of terms
that are neither defined in section 1.1 nor are common usage in the IP world.
These should be explained and/or the discussion of them should be dropped.
Examples are "security label" in section 1.2 of the architecture draft,
"red/black separation" in sections 4.1 and 4.2 of the ESP draft, and "security
level" and "multi-level security" in section 1.4 of the architecture draft.
- Compartmented mode workstations, multi-level security, and security labels
have not been discussed on this list as requirements for IPSP. I suggest that
the discussion of these be moved from the earlier sections of the architecture
paper to section 5, as with section 5.5 "Use in Compartmented or Multi-Level
Networks."
- Section 1.2 of the architecture draft repeats many of the same phrases in the
discussion of AH versus ESP. Better to abstract out and make definitions of
concepts such as "security gateway".
- Page 12 of the architecture document and various other places require
user-oriented keying. It's not at all clear what that means for (a) systems
that don't have userids (e.g. Windows); (b) services that operate on behalf of
multiple users (e.g. nfsd); (c) systems that forward data between interfaces.
I think (c) is supposed to be excluded by the words "... traffic originating at
that system," but those words are not repeated in the several places that
require user-oriented keying. At the least, I think there should be some text
discussing these issues.
In general, the network layer does not logically have access to user-related
information, and some implementations may find it difficult or impossible to
fulfill this requirement. I suggest that IPSP should not (a) force
implementations to violate the usual separation between network layers by
requiring the IP layer to know the relationship between packets and users; and
(b) should not rule out implementations that simply can't meet this requirement.
- There has been some discussion that ICMP messages will be returned by
destinations in some situations. These should be outlined in the architecture
document. What about denial-of-service attacks?
- Page 8 of the AH draft discusses an issue with ICMP. I find this paragraph
confusing. If a system returns an ICMP packet, then it could authenticate (or
encrypt) the ICMP packet itself. There should be no problem with the size of
the ICMP packet itself. Of course the included copy of the original rejected
packet may be truncated, making it impossible to authenticate or decrypt the
rejected packet. I think that's what the paragraph is saying, but it's not
very clear. Also, this paragraph really belongs in the architecture document.
- There has been a lot of discussion about whether the DES-CBC transport should
be required. I respectfully submit that there is a set of organizations and
individuals who MUST (in a much more significant sense of "MUST") obey U.S.
(and other nation's) laws and who will require an engineering solution to
provide exportable encryption. Either this engineering group can provide that
solution or someone will have to define an IPSECbis and an IPv6bis. The risk
is fragmentation of standards. Since the set of people affected by the export
laws is large, I argue that this working group should address the issue.
- Regarding traffic analysis (section 3.4 of the architecture draft, and
elsewhere): the ESP is helpful when used between two gateways. Someone
snooping the traffic between the gateways can track the traffic pattern but
can't see the source and destination addresses and ports of the packets that
flow between hosts behind the gateways. Inject some additional fake traffic,
and traffic analysis becomes much harder.
- Some of the detail in section 4 of the AH document is superfluous and should
be left to the individual transforms. In particular, the paragraphs that start
with "If a block-oriented..." and "When a keyed ..." contains text that might
not match some specific transforms. In fact, the description of the MD5
transform doesn't match that in the actual MD5 document.
- The double-application of MD5 described in section 2 of the MD5 draft has a
significant performance penalty. This is ironic given the discussion of
performance in the immediately-preceding section.
- Section 3.1 of the ESP draft says "... If no security association has been
established, the value of this field shall be 0x00000000." When and why would
this ever happen? In other contexts, these drafts claim that SPI zero is an
error and should never be used.
- Both the AH and ESP drafts have sections discussing security labels. I think
these belong in section 5 of the architecture document. Similar with the text
concerning multilevel security near the end of sections 4.1 and 4.2 of ESP.
Also the discussion of security labels near the end of section 4 of the ESP
draft.
- Logging requirements are inconsistent among the documents. For example,
sections 4.1 and 4.2 of ESP say that logging is a MUST in certain cases, but
section 4 of the AH draft says SHOULD in similar cases. I suggest that logging
is an implementation decision and/or configuration choice and hence should be
described as SHOULD.
- There's a stray reference to "Appendix A" near the end of the introductory
part of section 3 of the ESP draft.
- The paragraph starting "If the authentication process..." in section 4.3 of
the ESP draft is confusing, at least to me. Please clarify.
- Regarding the position of the Pad Length and Data Type fields in the DES-CBC
draft: (a) why aren't these defined in the ESP draft since they are common to
all transforms? Particularly the data type field since the tunnel/transport
mode choice is itself defined as an attribute of ESP not of the DES-CBC
transform. (Don't say that it would have screwed up the ESP header alignment;
that's a poor reason to violate architectural clarity.) (b) Putting these at
the end exacerbates the problem of truncated returned packets in ICMP
messages. If these were near the beginning, you could decrypt whatever part of
the returned packets you get. With the data type and pad length at the end,
they'll be truncated first - and they are needed for the reverse transform.
- What is the data type field value for transport mode?
Sorry for the length of this note; I hope the compensation is thoroughness.
Follow-Ups: