[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
swIPe comments
Steve Kent says:
> As for specific concerns about swIPe, yes, I do have several,
> based on a cursory reading the protocol. I think the SAID-like field
> should be larger.
Why specifically? Since its on a per host pair basis, 64,000 policies
seems sufficient -- the sum of the the number of TCP and UDP
sockets on a host only twice that. Is there a concern that two hosts
might want to have more than 64,000 key/policy identifiers between
them, or is there another notion here?
> It should be emphasized that this field is used to select previously
> negotiated security association options: the key(s), sequence number
> management rules, optional use of compression algorithms, security
> labels, etc. That argues against a structure for the field.
I assume you are just mentioning that the draft language should be
made to emphasize this -- that seems reasonable.
> I also would like to see the the sequence number field be made
> larger, or at least provide for negotiation of a larger field, to
> avoid the need to provide for rekeying during an association. My
> motivation for this field is not the same as yours, but rather as a
> means of detecting replay attepmts in a denial of service context.
Actually, I believe that this was to some extent envisioned. The
current field is 32 bits.
1) How large do you think it needs to be?
2) What exactly is the sort of attack you think could be played on the
current field?
> To that end, if an association elects to invoke this option, I'd
> like to see a more explicit and more stringent sequence number
> management algorithm spelled out, rather than leaving it to each
> implementation to decide.
There are several things that ought to be standardized but not part of
the "visible" layer of swipe. As an example, the exact algorithms for
using DES, 3-DES, IDEA, Skipjack (:-) and other ciphers with swIPe
ought to be standardized so that different implementations can
interoperate based purely on the written spec -- should swIPe ever be
made a standard my feeling is that this should be part of a seperate
RFC since the exact algorithms being used are visible only to the two
endpoints, which can feel free to negotiate the use of nonstandard
ones. Similarly, I would agree that good algorithms for the management
of the sequence number are important -- but aren't part of the
"surface" layer of swIPe since two hosts could easily negotiate
another one if need be and not harm any other hosts on the net.
I'd be interested to hear what you feel would be optimal algorithms
for managing the sequence number, by the way.
Perry
Follow-Ups: