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

Re: comments on draft 03 of SKIP

Christian Schneider wrote:
> > >    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?

If the IP header destination address points to the intermediate node, then
it *has* to process the packet. By doing this, it can look at the Master 
Key-ID. If there is none, then the .... [hesitate] ...

You are perfectly right. It matters. This demands that each final transform
owns a next-protocol field, which I assume each transform defined as an RFC
will have.

> But not all ESP transforms contain a next protocol field (namely the ones 
> using the PKCS #7 padding scheme), right?

We will have to change our internal SKIP ESP transforms to *have* an next
protocol field.

> The whole padding stuff is unnecesserally complicated IMHO. One padding scheme
> should be sufficient.

I agree. But we will not see a change to the padding scheme in RFC 1829 in
the next few years, I believe. ;-)

> My proposition would be to adopt the AH scheme, i.e. start with Next 
> Header and Length fields (meaning payload type and padding len).

Any comments from other SKIP implementors? Perhaps you want to fix the
'correct' behaviour for the SKIP internal algorithms, as proposed in my
comments to (02)?

> 
> 
> > > 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.

What were the problems with the sequencing as proposed? I thought using a true
counter would be okay, as long as
a) the counter resets when Kp changes
b) Kp changes frequently enough to recover from deadlocks
c) No Kp is reused before 'n' is updated.

Comments?

> > 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?

I do not believe so. The ICMP message is used only to coordinate algorithm
usage between two machines. The UDP certificate discovery? protocol is used 
to get the key partaining to a Master Key-ID.

Germano