[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ESP Pad byte changes
VPNet implements both the pad fill and the pad check. We made
the pad check a 'tunable' parameter for interoperability testing
because when we first implemented it, we were unable to talk to
anyone. For the production release it is non-tunable. At the
Raleigh workshop, most people we tested with had implemented the
pad fill. Generally, when we found someone who had not implemented
the pad fill, it took them well under an hour to add it to their
code.
rwt
> -----Original Message-----
> From: Jackie Wilson [mailto:jhwilson@austin.ibm.com]
> Sent: Wednesday, April 08, 1998 10:22 PM
> To: ipsec@tis.com
> Subject: ESP Pad byte changes
>
>
> I was wondering how many implementations are numbering the
> pad bytes and
> checking the values as indicated in the latest ESP draft.
> This seems to be a
> problem that if you check the values, you may not be able to
> interoperate with
> many ipsec implementations. I realize this is a 'should'
> issue, but this
> is a low-level detail I don't want to surface to the user to
> turn on or
> off. In addition, it is not an attribute that can be negotiated with
> ISAKMP/Oakley. Is checking the pad numbering strategic, do
> most implementers
> plan on doing it? Are most people making this a configurable
> option? If it's
> not being done now, are people planning on doing it soon (ie
> 1998)? If it
> is not important from a security standpoint to have it, then
> why is it in
> the draft?
>
> For all the noise made about freezing the drafts, I question
> the decision
> to add this in the last round of changes to ESP.
>
> Just wondering what others thought.
>
> Jackie
> --
> Jacqueline Wilson | Phn: (512) 838-2702
> IBM, AIX/6000 | Fax: (512) 838-3509
> 11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678
> Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com
>