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