[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on ipsec-arch-sec-01.txt

The following bullets are comments on the 01 revision of the IPsec
Architecture document.  Some of this I stated at or before Munich.  With
Bob and Ted's push to advance these documents, I wanted to make sure I spoke
my peace.

* It is my opinion that, while there are processing differences between
transport and tunnel modes of IPsec, to explicitly distinguish them as an SA
attribute is wrong.  They should be "Selectors" in your abstraction of the
Security Policy Database.  I may wish to use a pair of SAs for both tunnel
mode and transport mode simultaneously.  The differences between tunnel and
transport mode are important, but they should be indicated with respect to
processing and policy decision making, rather than be an explicit SA
attribute.

* While I'm on the subject of tunnel mode and policy, I'd like to show an
example of why it is so important to get policy enforcment correct.  This may
seems obvious to some, but a naive implementation may not correctly handle
this case.  Furthermore, I recall this being in earlier version of the IPsec
architecture.  Consider the security gateway example...

  <subnet a.b.c/24> ---- SG =======(The Internet)======== SG' --- <a.b.d/24>

It is important to note that SG may accept legitimate SA establishment
requests from parties other than SG'.  If this is so, it is CRUCIAL that SG
take care that a malicious party M doesn't use its legitimate SAs to tunnel
forged packets from a.b.d.X to a.b.c.Y.  A naive SG implementation may say
"Oh, it was decrypted, of COURSE I can forward the inner packet" regardless
of WHICH PEER SG sent it.

* In section 4.3, there's a sentence that reads:

	... SAs that comprise a bundle need may terminate...

  "need may" was probably a typo.

* You may wish to site GKMP as work in progress for multicast key
distribution in section 4.7.

* In section 5.2 (Inbound IPsec processing), you have reassembly at the END
of the steps, rather than at the beginning.

* For section 6 (ICMP processing), the question is do you trust the sender of
an ICMP packet?  If the router that sends the ICMP packet first does a
full-blown ISAKMP initiation sequence, I suppose you can trust that it came
from that router.  A discussion of ICMP trust, and the "advisory" role of
ICMP probably is needed.

* BTW, if a bump-in-the-stack implementation of IPsec attempts to apply
different IPsec algorithms based on the ports is sniffs, it is difficult to
apply Path MTU adjustments.

* In performance issues, the initial ISAKMP (or Photuris, etc.) processing
overhead will be felt in the first packet, and is analogous to ARP resolution
or IPv6 Neighbor Discovery.  The question is, will the exchange cause a TCP
to retransmit the SYN before the exchange is done?  (I wish the ANX sessions
talked about this.)

* My aforementioned example is probably a good candidate for "Security
Considerations".

Hope this helps,
Dan
Follow-Ups: