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

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


--- On Mon, 22 Sep 1997 21:15:24 -0500  Stephen Kent <kent@bbn.com> wrote:

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

   Requiring that the tunnel/transport-mode distinction be part of the SA
   will break several existing implementations that my employer is using.
   It also goes against the grain of not changing the specification in a way
   that makes existing conforming implementations non-conforming.  I would
   also request that it be deleted as a mandatory or recommended SA attribute.

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

  I consider it valuable to note the serious problems with unauthenticated
  ICMP messages.  If these aren't noted, some well-intentioned but naive
  implementer might actually code up Simpson's proposed ICMP extensions,
  thereby creating a security problem for that implementation.  By at least
  clearly noting the issues, a naive implementer can become informed.

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

  Perhaps its useful to note in more detail how much extraordinary effort is
  required to get a BITS approach to work properly.  I suspect that most of
  the BITS implementations won't go far enough to really make things work
  properly.

  Personally, I don't believe that the BITS approach is necessary given that
  various vendors have already shipped stacks for Windows that include IPsec
  and Microsoft has IPsec code being written for its stacks.  The historic
  justification for the BITS approach was Microsoft systems.
Follow-Ups: References: