[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSEC Last Call: SA definition
Folks (in particular Theodore),
I'm a little bit behind on the flood of E-mail and may have
missed any true "last call" deadline but I'm concerned about a couple
of notes that flew by in the last 2 weeks. I want to make sure we
didn't change the definition of an SA, at least as far as how a receiver
is supposed to be looking things up and conceptually managing its
database of SA info.
In the current arch-sec-04 we have the following from section 4.1:
A security association is uniquely identified by a triple consisting
of a Security Parameter Index (SPI), an IP Destination Address, and a
security protocol (AH or ESP) identifier. In principle, the
Destination Address may be a unicast address, an IP broadcast
address, or a multicast group address. However, IPsec SA management
mechanisms currently are defined only for unicast SAs. Hence, in the
discussions that follow, SAs will be described in the context of
point-to-point communication, even though the concept is applicable
in the point-to-multipoint case as well.
In both the esp-v2-04 and auth-header-05 documents we have text that
mirrors each other (this one in ESP):
3.4.2 Security Association Lookup
Upon receipt of a (reassembled) packet containing an ESP Header, the
receiver determines the appropriate (unidirectional) SA, based on the
destination IP address, security protocol (ESP), and the SPI. (This
process is described in more detail in the Security Architecture
document.)
The above supports the arch-sec-04 definition of a unique triple but
doesn't force it to be an explicit triple, it says "based on".
In recent E-mails to the IPSEC list we have:
on 4/7/98 in the "Re: why single value destipaddress in SA selector"
thread from Karen Seo (sent soon after, but probably without seeing, a
message from Michael Richardson on the same date had given what *I*
thought was the correct response on how multiple flows get mapped to a
single tunnel SA, without changing the definition of an SA):
Padma,
>>According to the Ipsec Architecture RFC, Destination address part of
>>selectors can have single, range, wildcard in SPD but SA can have only
>>single IP address. Why is it so? Why can't we have range or wildcard
>>in SA dest ip address part of selectors as in SPD.
You're right. We will change the 2nd entry in the table on page
21 from:
Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
--> dst addr single IP addr single IP addr single,range,wildcard
to:
Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
--> dst addr single IP addr single,range,wild single,range,wildcard
By the way, Karen's note goes on in well-done detail (sorry, Michael,
she went much further than you) to explain the proper use of the
destination address depending upon Transport vs. Tunnel mode as well as
the proper mapping of policy to a Security Association in the original
E-mail's tunnel example. I was left with the impression that the
"triple lookup", just as in a hash lookup, would satisfy the
requirements she described for the "index" usage of "dst addr". At
least for the initial "lets get some info on what this inbound IPSEC
packet is about" lookup and "lets get some info on selectors specific
to this SA for this inbound packet".
However, the above table change seems to lead to the note below,
perhaps because the table doesn't/can't specify the destination clearly
as being used for index/lookup vs. selector usage and whether by the
sender or a receiver:
on 4/16/98 from Theodore Y. Ts'o responding to Baiju:
1. Destination address: The destination address is part of SA.
Therefore, it is not possible for the recipient of the packet to
correctly identify SA used to protect the packet, and thus, ESP
integrity check will fail.
2. Source address: As defined in the IPSEC Arch document, SA database
includes this information, and therefore, when compared with expected
source address for the SA, any change in the source address will be
detected (thus, integrity violation will be detected).
The destination and source addresses in the SA may be a wildcard, or a
range of addresses, not just a single address. Hence, changes to source
and destination addresses may not be detected unless you are using
something like AH to integrity protect these header values.
7. If protocol field is changed, SA lookup will result in the SA that
was used to protect the packet. So, integrity will not be verified.
The protocol field is not used to lookup the SA. The SPI is used to do
that.
My belief is that Karen's full note from 4/7/98 is correct and that
Theodore's note is not completely correct on the above 2 comments,
without more qualifications. But either way we're left with an
apparent need for more clarification in the architecture document. I
wouldn't think it worthwhile to hold up "last call" for that
clarification as long as someone (Theodore?) clarifies this apparent
discrepancy on the mailing list. An SPI-only lookup with a wildcarded
or ranged SA destination address as "index" on receiving an IPSEC
packet would have some ramifacations that I'd rather we didn't
introduce at this time on working implementations. I thought they'd be
more appropriate for IPsecond or the NAT presentation Bellovin made at
the last IETF's NAT meeting for our consideration.
Thank-you.
-- Marc --