Re: Thomas Narten's DISCUSS vote

Vipul Gupta <vgupta@nobel.Eng.Sun.COM> Fri, 22 May 1998 21:34 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03079 for ipsec-outgoing; Fri, 22 May 1998 17:34:05 -0400 (EDT)
Date: Fri, 22 May 1998 14:42:38 -0700
From: Vipul Gupta <vgupta@nobel.Eng.Sun.COM>
Reply-To: Vipul Gupta <vgupta@nobel.Eng.Sun.COM>
Subject: Re: Thomas Narten's DISCUSS vote
To: tytso@MIT.EDU
Cc: ipsec@tis.com
Message-ID: <libSDtMail.9805221442.8726.vgupta@nobel>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset="us-ascii"
Content-MD5: DwdbVmEJO1/+xlt94QHpaA==
X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

  I think Tom's comment is valid. Even when used with NULL encryption, 
  ESP's integrity check will include the TCP/UDP header and,
  in particular, the TCP/UDP checksum field. Since this
  checksum is computed over a pseudoheader which includes
  the IP src and destination, a NAT box would need to
  update the checksum whenever it updates the IP src/dst
  fields.
  
    Unless the NAT box has knowledge of the SA parameters
  protecting the traffic, one of two things will happen:
   - IP src/dst is updated but not the checksum =>
     transport checksum failure at the receiver
   - NAT box changes IP src/dst and updates checksum =>
     ESP integrity failure at the receiver
     
  vipul
  

> >
> >>     The NULL Encryption Algorithm and Its Use With IPsec [PROPOSED]
> >>        <draft-ietf-ipsec-ciph-null-00.txt>
> >
> >
> >>    The IPsec Authentication Header [AH] specification provides a similar
> >>    service, by computing authentication data which covers the data
> >>    portion of a packet as well as the immutable in transit portions of
> >>    the IP header.  ESP_NULL does not include the IP header in
> >>    calculating the authentication data.  This can be useful in providing
> >>    IPsec services through Network Address Translation (NAT) devices and
> >>    non-IP network devices.   The discussion on how ESP_NULL might be
> >>    used with NAT and non-IP network devices is outside the scope of this
> >>    document.
> >

 [Tom Narten wrote:]
 
> >Comment about NAT seems very questionable, since all useful protocols
> >that run on IP (i.e. TCP/UDP) have a pseudo-header that depends on the
> >addresses.  I suspect the authors were thinking that with the payload
> >in the clear, NAT could update the checksum. However, the AH check
> >will not allow that. Suggest removing text.

 [to which Ted Tso responded ...]
  
> The text is valid; ESP includes integrity protection, although ESP
> doesn't cover the IP header.  In the new IPSEC scheme, it is extremely
> unlikely that someone will use both ESP and AH.  ESP-NULL provides no
> data confidentiality, but it does provide integrity over the packet data
> (but not of the IP headers), thus allowing NAT boxes to muck with the IP
> headers.  
> 
> Whether or not this is a horrible abstraction violation is besides the
> point; if the goal is to allow NAT boxes to work, while still providing
> data integrity services for the packet contents, ESP NULL is one way of
> accomplishing that goal.