[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSEC SA doc comments
I haven't been able to read this as thoroughly as I would have
liked; in spite of the saying, time has done nothing to make
certain that everything doesn't happen at once (well, sleep isn't
happening too much, so hopefully this is somewhat coherent).
The cross-checking between documents that I had hoped to do
didn't happen [apart from what I can reconstruct from memory or
my interpretation of things]; sigh.
1. Is ippcp a WG yet?
2. Section 4.2, last paragraph. To me, the SA granularity plays
a big part in the traffic flow confidentiality. A granularity of
a single session, even running in tunnel mode, isn't as useful
(traffic flow confidentiality-wise) as a single tunnel securing
possibly multiple streams. In the mobile user case, the only thing
that is really hidden is the identities, but probably not much in
terms of "what is going on" ("the SYN packet is happening here").
3. Section 4.3. In the discussion of iterated tunnelling, something
should be said about what to do w.r.t. ISAKMP packets. In the case of
H1 -- SG1====SG2, where H1 has a pipe with SG2, and those packets
are subsequently reencapsulted in SG1, do the H1-SG2 ISAKMP packets
get stuffed in the tunnel?
The informal poll at the Detroit bakeoff said "yes". But this hasn't
really been put down anywhere. But, if the "iterated nesting" occurs
between the same systems, what then? [It may pan out just fine, but
this thought just crossed my mind while typing this; we need to make
certain if we do such stuffing that we cover the various scenarios.]
4. page 14, last full paragraph. Last sentence, starting with "For
each selector...". I'm not understanding scenario (a).
5. I'm not comfortable with the statement that an SA can be used
in multiple SA bundles. I just tried to write something here, but
I'm having a hard time describing it. It may simply be because
my mental model of an "SA bundle" has been what has resulted from
a single ISAKMP negotiation, which differs from the definition
used here. I need to go back and convince myself that I do or don't
have an issue here.
6. For various reasons, the DOI does not match the SA document in
terms of what can be used as SA selectors. If I can't negotiate
it in an ISAKMP exchange, I can't consider using it as an SA
selector (which is different from saying what kinds of selection
criteria I will use in referencing my SPD).
The DOI does not support ranges of anything except IP addresses, and
it does not support lists of anything. Putting down these selectors
as a MUST requirement is going to collide with a document that now has
completed last call. [I mentioned this as an issue in Munich, but it
didn't get resolved.]
7. Related to (6): I can see where ranges and lists can be nice
things; I've wished for them myself for ports, for example. However,
since the ISAKMP exchange is effectively one where the responder
can't refine the settings given by the initiator (except for selecting
one transform proposal from the list), if the responder does accept
part of the specified range/list, but not all of it, the responder is
forced to reject the whole request. There is no mechanism for the
responder to say "yes, but for only a subset of the requested
identities". This problem already occurs when using subnets, but
somehow in my mind it could be worse in the case of ranges (especially
if what the initiator requests and what the responder accepts
partially overlap).
While on the general subject, I've always thought that "negative
entries" could be a nice idea (specify a range, and then punch a
hole in it, e.g. "everything here except SMTP traffic"). Still, the
massive complexity of such a thing would be too horrific. The
dirty secret in effect is that the sender may send traffic through
the pipe that he thinks is allowed/accepted by the receiver, to
(possibly) discover that the receiver may drop it on the floor
because it was that SMTP traffic... [In this case, the sender isn't
the initiator of the original ISAKMP negotiation.] I don't see a good
resolution to such a thing (apart from some sort of separate tunnel
establishment protocol), except by making it quite clear in the
document that such things can happen.
8. Page 17. I don't understand having "IPSEC protocol" as a separate
SA selector field (separate from "protocol".
9. The DOI also doesn't specify TOS.
10. I jotted down a note about "accepting finer-grained requests in
SAs". I think it had to do with the SPD search to find the appropriate
SA, where once there is a "hit" in the SPD, that the SADB search
needs to find the finest-grained SA entry that covers the traffic.
And also that as a responder I'll accept something that falls
within the range of a particular SPD entry.
My SPD may say "subnet A to subnet B", but I may have an SA from
"host A.1 to host B.2", and another one from "host A.1 to host B.3".
It's as if the SPD entry pointed to a small tree of SA entries.
I wrote down this note, but I didn't try to go back and see if this
was described anywhere...
11. Page 23. To support the following:
IP(dest=B, src=A) + AH + IP(dest=B, src=A) + ESP + transport data
will require two ISAKMP negotiations, one for the tunnel mode
part (SA selectors = A/B, prot = AH), and one for the transport mode
part (SA selectors = A/B, prot = whatever except AH).
That isn't a problem (I don't think), just an observation. For one,
I don't think (and any ISAKMP geeks can correct me on this, but the
current resolution document still looks that way), a single
SA negotiation only includes a single pair of identifiers (SA
selectors as it were). For another, you may want the outer tunnel
to support multiple transport sessions.
12. Page 31. If a single ISAKMP negotiation results in a pair of
SAs (AH+ESP) per direction, I would want to make certain that if
SAs (AH:300 + ESP:410) were established together, that they both exist,
in that order, in the received packets. I won't allow AH:300 + ESP:500
for example, even if ESP:500 exists and is from the same source as
410.
13. ICMP processing: I assume we're talking about errors, and not
about things such as echo/reply.
14. Don't subject the router-generated ICMP message to source address
checks? Huh?
15. Propogation of PMTU, page 33, last line of second-to-last bullet.
In reading the last line, it seems to me that the behavior is beyond
that required by a tunnel. Why should the "immediate return of a
path MTU message" be a MUST? [I don't have the relevent RFC handy,
so I can't check this out myself.]
16. Page 35, first full paragraph. What's the general opinion been
of using the behavior described in RFC1191 as opposed to what's
been described in RFC2003? [I'm talking about the issue of whether
or not to forward the packet through the tunnel anyhow if it's too
big.] The poll I did on the anx-sec list seemed to run off on a
tangent here.
17. Michael Richardson had brought up the question: "if an
intermediate system receives a PMTU message not targeted toward it,
but where forwarding would stuff it into an IPSEC tunnel, should
that message be forwarded?" [Michael can correct me if I'm misquoting
him ;-).] Anyhow, has there been some resolution to this scenario?
18. Go through the References and see if they're still being used
in the document. I was a bit suprised to still see a reference to
[Hugh96] for example. Also, make certain they still exist (in the
case of I-Ds).
- C
Follow-Ups: