[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: swIPe available for FTP.
I'm going to forward your comments on to ji; Matt is already reading
the group. There should be an explicit statement in the definition
that packets not conforming to a policy should be dropped. If I'm
using a policy for communication between two hosts on a particular
higher level service, if it isn't encrypted in the policy it should go
on the floor -- possibly after having been logged.
There IS a way for the higher levels to determine what policy is being
applied to packets -- via ioctls in the implementation. The interface
should perhaps be better documented.
Perry
smb@research.att.com says:
> Apart from problems with the architecture, there are three serious
> flaws in the implementation.
>
> One, of course, is the lack of key management. That's known and admitted.
> Indeed, swIPe is a good vehicle for experimenting with it.
>
> The second problem is the lack of filtering on input. That is, you
> may have a key -- which guarantees authenticity -- between you and
> some host Foo. But no check is made to ensure that packets from Foo
> are properly encrypted. This means that you can't trust a received
> packet; you only know that genuine packets haven't been tampered with.
>
> Third, there is no notice to the higher levels -- TCP or the application --
> of the security status of the received packet. This makes it difficult
> to build a secure application on top of swIPe.
>
> swIPe isn't useless, by any means. But a lot more work is needed to
> make it really useful.