Wild guess here: it was done to allow hardware authentication to be more easily implemented?
Somebody out there must know the reason.
---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Stephen Waters [mailto:Stephen.Waters@digital.com]
> Sent: Thursday, November 05, 1998 10:18 AM
> To: Tim Jenkins
> Cc: ipsec@tis.com
> Subject: RE: IBM VPN Bakeoff Issues
>
>
> Yes, I know what it says - I was wondering why it said it.
> Can you clarify?
> Steve.
>
> -----Original Message-----
> From: Tim Jenkins [mailto:tjenkins@TimeStep.com]
> Sent: Thursday, November 05, 1998 2:13 PM
> To: Stephen Waters
> Cc: ipsec@tis.com
> Subject: RE: IBM VPN Bakeoff Issues
>
>
>
>
>
> ---
> Tim Jenkins TimeStep Corporation
> tjenkins@timestep.com http://www.timestep.com
> <http://www.timestep.com>
> (613) 599-3610 x4304 Fax: (613) 599-3617
>
>
> > -----Original Message-----
> > From: Stephen Waters [ mailto:Stephen.Waters@digital.com
> <mailto:Stephen.Waters@digital.com> ]
> > Sent: Thursday, November 05, 1998 9:02 AM
> > To: Tim Jenkins
> > Cc: ipsec@tis.com
> > Subject: RE: IBM VPN Bakeoff Issues
> >
> >
> >
> >
> > > 12. Does ESP-NULL require padding (the ESP doc says 4-byte
> > alignment,
> > > ESP-NULL doc says 1-byte alignment). The consensus was
> that ESP is
> > > 4-byte aligned.
> >
> > There is no ambiguity. ESP in general requires 4 byte padding
> > or a multiple
> > of 4. ESP-NULL has a block length of 1. Since the padding
> used for a
> > particular combination of ESP and an encryption algorithm is
> > the lowest
> > common multiple of 4 (from ESP) and the block length of the
> > cipher, the
> > result is that ESP with the NULL cipher uses a padding of 4
> > (or 8, or 12,
> > ...)
> > [[SW]] There may not be any ambiguity, but there is
> contradiction and
> > confusion :) We're not talking about 'ESP in general' though,
> > right, this is
> > NULL-ESP, and I don't understand why NULL-ESP should have any
> > padding, let
> > alone 4 bytes. NULL-ESP actually means ESP-Authentication,
> > and the mandatory
> > authentication algorithms don't need padding. One problem is
> > where folk
> > want to pad for other reasons - then your left with the
> dilemma of not
> > knowing if it was applied or not. With PPP ECP, if there is
> > no need to pad,
> > but the last octet of data could be taken for a pad length,
> > then explicit
> > padding is added. Since the pad length can be 0-255, I guess
> > that means a
> > pad length is mandatory, but why can't I just add a single
> > byte with value 0
> > if I'm not interested in padding?
>
> The ESP document specifically says you must effectively have
> 4-byte padding
> requirements (including the Pad Length and Next Header fields).
>
> Start Quote:
>
> o Padding also may be required, irrespective of encryption
> algorithm requirements, to ensure that the resulting
> ciphertext terminates on a 4-byte boundary.
> Specifically, the
> Pad Length and Next Header fields must be right
> aligned within
> a 4-byte word, as illustrated in the ESP packet
> format figure
> above, to ensure that the Authentication Data field (if
> present) is aligned on a 4-byte boundary.
>
> End Quote
>
>
> >
> > > 16. If an initiator requests an SA with only a single IP
> address as
> > > the destination, but the responder has a local policy of a subnet
> > > (instead of a single IP address), should it fail the negotiation?
> > > Some vendors were doing this.
> >
> > Yes, it should fail. Because then the initiator could then
> > request another
> > SA for the next IP address in the range the responder wanted
> > to use in the
> > first place. And then the next one. So you end up with a
> > whole bunch of SAs
> > that you don't need, and you may end up with a management
> > issue that you
> > didn't want. If your system is configured for a subnet, than
> > that's probably
> > what the administrator wants.
> > [[SW]] The architecture does discuss how policies can cause
> > the creation of
> > SA where the selector values are taken from the packet (or
> > the ISAKMP ID
> > payloads I guess), so this sounds like a management issue
> > where the response
> > will be determined by the options set on the policy.
> >
> >
> >
>
> I'll reverse my position on this one. Both you and Dan H.
> have pointed out
> that this should be a local implementation decision, not a standards
> decision.
>