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

Re: Comments on IPSEC work


Paal Hoff says:
> 1) Comments on the swIPe protocol:
> 
>    - It is unclear why the author introduces an additional protocol
>      type (the IPPROTO_SWIPE).

Because the concept of swIPe is to provide security via encapsulation,
so that existing IP implementations can transparently interoperate
with secure routers and systems.

>      Maybe the idea behind this was to
>      leave the IP input routine unchanged and to add SWIPE as a
>      new protocol that IP may include in it's protocol switch for
>      higher layer protocols.

I don't believe that implementation concerns played a part. I think it
was the notion of IP in IP encapsulation for security that played a
part. IP encapsulation allows one to shield against traffic analysis,
do secure bridging, secure connections between hosts, etc, all with
one simple and elegant paradigm. It easily accomodates multiple levels
of security policy and other nice features -- two hosts can be
connected by a secure connection and the connection might have a
secured link in it without their needing to know and without the
routers implementing the secured link needing to worry.


>      However, the protocol type field of the IP header cannot be
>      trusted, so such an implementation architecture would provide
>      an intruder with a very easy way of bypassing the securiy
>      functions.

I'm sorry, but I don't understand why this would be the case at all.
Assuming that your implementation is properly constructed, it would
not be trusting IP header contents to be correct and would only accept
swIPe packets as having been definatively authenticated. In
particular, a proper implementation will not accept non-authenticated
packets for a hostpair/protocol/port tuple that is already being
handled by a secure policy.

>      I assume therefore that the "policy engine" of the swIPe prototype
>      uses other information (such as src and dst IP address) to decide
>      what to do with a received packet.

This is not an "assumption" that you need to make -- that should be
extremely clear from the design.

>      Note that it will always be necessary to change the IP input code
>      to avoid bypass problems, so I can see no justification for
>      introducing the IPPROTO_SWIPE protocol type.

As I noted, the whole notion is security via secure encapsulation.
Thats why you need the protocol.

>    - The swIPe protocol claims to support a "wide variety" of crypto
>      systems. Well, this wide variety actually excludes all stream
>      ciphers.


I see no reason that this should be the case.

>      If you use a stream-cipher, you will have to carry
>      some use-and-discard crypto synchronization per packet, such as
>      a random IV or an encrypted random packet encryption key.
>      There is no room for this in the swIPe header.

It needn't be in the header. If a policy is to be implemented with a
stream cypher, the first bytes of the packet itself might contain the
needed synchronizing information apart from the swIPe header qua swIPe
header. Bits are bits, you know. swIPe does not overspecify the
contents of the packet itself -- some of that can be handled on a per
encryption system/policy basis. 

>    - The packet sequence number of swIPe introduces a semantical
>      problem, since an IP protocol engine does not know which transport
>      connection a given datagram belongs to.

So?

>      The architecturally clean way to protect against replay is to
>      include sequence numbers in higher layer protocols,

These have not to my knowledge been abolished, you know.

> 3)   Comment on the need for a new layer 3 security protocol:
> 
>      As Paul Lambert said at the ISSNDSS '94 no flaws or errors
>      has been detected that makes SP3 unsuitable or inappropriate
>      for use as a security protocol for IP.

Does being big and ugly and inflexible count?

One of the things I like about swIPe is that its extremely simple and
still potent.  Minimal changes to the way we do business yield an
extremely flexible and powerful mechanism on which to implement secure
networks. I find short specification documents and simple design to be
an enormous feature, especially in discussing security. As Marcus
Ranum has mentioned more than once, anything too big to keep in your
head at once is too big to trust. If you can't recall all the details
of the spec off the top of your head, the system is too big to ever be
truly bug free.

Perry
References: