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

Re: Comments on ipsec-arch-sec-01.txt

Dan,

>* 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.

We agree that tunnel vs. transport mode needs to be in the SPD.  Depedning
on the context of the IPsec implementation, I think it will be necessary to
specify that as an SA attribute, but I'm willing to remove it there is
agreement among implementors that not all implementations will need this
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.

I too pushed for checking incoming IP source addresses against SA
parameters long ago, for precisely this reason, but somehow it didn't make
it into the I-D.  I'll correct that omission.

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

In paring down the Arch Doc, we'll just make passing mention of this, and
defer the problem for now.

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

We'll go back and fix it.

>* 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.

We may defer most of the ICMP issue, or make a simple statement about the
"do you trust the source" problem.

>* 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.

Yes, it is, but I've been asked to not rule out BITS implementations that
take extraodrinary measures to compensate.

>* 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.)

Good point.

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

Which example?

Steve
Follow-Ups: References: