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

RE: IBM VPN Bakeoff Issues

O.K. - there may be a reason somewhere for wanting to add pad, but that
sounds like an implementation issue - why make it a MUST to be four-byte
alligned?  It should be a MUST to send and process-on-receive whatever
padding is required/added, but the software/hardware-encryption I'm using
doesn't need it, so I want to use a pad-length of zero on all my Tx
ESP-Authentication packets.
 
Cheers, Steve.

-----Original Message-----
From: Tim Jenkins [mailto:tjenkins@TimeStep.com]
Sent: Thursday, November 05, 1998 3:40 PM
To: Stephen Waters
Cc: ipsec@tis.com
Subject: RE: IBM VPN Bakeoff Issues



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
<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 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
<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>  
> < 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>  
> < 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. 
>
Follow-Ups: