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

More swIPe Comments...Better late than never


The best feature of swIPe that I like the most is its simplistic approach.
I have been told of and have seen simple security protocols end up in
nightmares of complexity once everyone has had there say and added
security features to protect against any/all possible attacks.  Having
said that, the following are not presented in any implicit order.

1.  There seems to be possible redundancy between the Packet type and the
    Policy Identifier.  What is gained by having the Packet type
    contained in the header as long as this information can be
    conveyed by the Policy ID?

2.  I am still unconvinced that the benefits gained by adding
    a sequence number to a connectionless protocol out-weigh the
    costs attributed by the added complexity.  I'll decline to argue
    further on this point though until I've actually tried to implement
    it.

3.  In the definition of the Packet sequence number field it is stated that
    this field "may also be used for synchronization by a stream cipher".
    Later in the Draft the text describes that the sequence number is
    copied to the packet; Authentication is applied from the second
    1/2 of the swIPe header to the end of the data, Encryption is applied
    to the same.  I assume that this isn't quite right, because you
    cannot encrypt the sequence number field and still use it for 
    synchronization.

4.  The statement "The algorithm may require padding, which is appended 
    to the packet after encryption has been performed." is slightly 
    confusing.  There is some implication here that the Pad field is not
    encrypted.

5.  It has been pointed out to me that for reasons of efficiency,
    it may be optimal to have the Authenticator at the end of the packet.
    I am not convinced of this, but I thought I would mention it.

6.  Since efficiency (both # bytes on the wire and speed of processing) 
    is a key issue with some folks, it seems to me that including an
    extra IP header in every single packet (requardless of whether 
    swIPe is running End-to-End or between routers) is inefficient.

    The extra IP header is only needed when using swIPe with a router
    (ie., Host to Router or Router to Router).  In Host mode you could
    exclude the internal header and only have to process the packet
    through IP once.  It is not too difficult to use the Policy
    identifier (or Packet type if 1. is ignored) to implement this.
    Explaining this is probably more difficult than implementing it.

7.  A lack of some type of Version number in the packet header is 
    painful at best.  It has been argued that this information could
    be conveyed in the Policy ID (SAID).  This doesn't work well.  If the
    Policy ID field were to become larger in a future version, performing
    a Policy lookup would be difficult if you didn't know what version(s)
    were supported/implemented.

8.  While no Key Management is specifically defined by swIPe, it is 
    useful to identify those Key Management attributes that directly
    relate to swIPe's operation (eg., algorithms, keys, authenticator
    length, etc.).

9.  The comments on traffic analysis only relate to Router mode operation
    of swIPe.

10. What value is obtained by encapsulating but not providing authentication
    or encryption (ie., packet type 0).


Just my two cents....

Rob G.
glenn@osi.ncsl.nist.gov