[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft 03 of SKIP
> > 2. There are two modes in ESP, tunnel mode and transport mode.
> > This information is not on the SKIP header. How does an
> > intermediate node which is encrypting/decrypting SKIP packets
> > for multiple machines know whether the entire IP datagram is
> > encrypted or only the upper-layer protocol ?
>
> a) does it matter?
Yes. You have to either append the original IP header or use the IP header from
inside the ESP payload to forward the packet. So you have to know, haven't
you?
> b) by looking at the next protocol field.
But not all ESP transforms contain a next protocol field (namely the ones using
the PKCS #7 padding scheme), right?
The whole padding stuff is unnecesserally complicated IMHO. One padding scheme
should be sufficient.
I generally dislike the PKCS padding and I don't like the RFC 1829 having its
padding and especially the payload type after the payload. This makes it
necessary to decrypt the payload prior to being able to decide whether tunnel
or transport mode is used and has some negative effects on efficient
implementations. My proposition would be to adopt the AH scheme, i.e. start
with Next Header and Length fields (meaning payload type and padding len).
Something like:
+---------------+---------------+---------------+---------------+
| Security Parameters Index |
+---------------+---------------+---------------+---------------+
| Next Header | Length | RESERVED (or remove this) |
+---------------+---------------+---------------+---------------+
| IV |
+---------------------------------------------------------------+
| Payload Data (padded) |
+---------------------------------------------------------------+
> > 3. Why is sequencing dropped in draft 3 ? The n counter provides
>
> That is a *very* good question. I would like to see this feature back,
Probably because the proposed sequencing does not work. A working yet has to be
proposed I think.
> > The Algorithm discovery message does not contain NSID nor Master Key-ID.
> > Will this allow different encryption algorithms to be used for
> > different Master Key-IDs ? or between two systems ?
>
> I see no need for multiple encryption algorithms between two machines at one
> point in time.
There are some pointers towards user-oriented Master-Keys propagated from upper
level protocols (Social Security Number et altera). This suggests being able to
send Master Key-IDs with an ICMP message, wrong?
- Chris
--
Chris Schneider - cschneid@amiga.icu.net.ch BIX: hschneider IRC: cschneid
Computers are not intelligent. They only think they are.