[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: Why can't ESP authenticate IP header?
From: Stephen Kent <kent () bbn ! com>
Date: 2001-09-26 7:49:51
[Download RAW message or body]
At 7:11 PM +0530 9/25/01, lokesh wrote:
>
>
>----- Original Message -----
>From: <mailto:kent@bbn.com>Stephen Kent
>To: <mailto:lokeshnb@intotoinc.com>lokesh
>Cc: <mailto:ipsec@lists.tislabs.com>ipsec@lists.tislabs.com
>Sent: Tuesday, September 25, 2001 6:13 PM
>Subject: Re: Why can't ESP authenticate IP header?
>
>At 10:25 AM +0530 9/25/01, lokesh wrote:
>
>>As noted, ESP coverage of selected header fields would increase
>>complexity and reduce performance. It also would create even more
>>circumstances where NAT could interfere with IPsec use. Today,
>>using ESP in tunnel mode can be made to work with NAT, but if the
>>outer S/D IP addresses were covered, that capability (I hesitate to
>>call it a feature) would go away.
>>
>>
>>
>>Steve,
>>
>>
>>
>>As for as I know, in many implementations, NAT is done prior to
>>ipsec processing at the sending end, and Ipsec processing is done
>>before NAT at the receiving end.
>>
>>Are there situvations where NAT would interfere in ipsec processing
>>? if so, kindly will you brief them?
>>
>>
>>
>>Assuming there will be situations where NAT will interfere with
>>IPsec processing, how AH in transport mode will work there?
>>
>
>I get the feeling that you have not been reading this list for very long.
>
>Yes, a combined IPsec/NAT implementation in a security gateway
>avoids the problems I cited. The NAT problems I refer to arise when
>NAT takes place at a device that is between the IPsec implementation
>and the Internet. For example, I am in a hotel room in London now
>and if I had IPsec on my laptop, it would have to deal with the NAT
>box that the hotel has deployed. Same problem arises in many cable
>modem nets, and for desktop IPsec implementations in corporate
>environments where NAT is performed at the gateway/firewall.
>
>Steve,
>
>yes , I have subscribed it very recently,
>
>in such scenarios, as the one you mention above, I think AH in
>transport mode should not be used right?
>
>Thanks
>-Lokesh
AH in any mode will break in these contexts, as will ESP in transport
mode, but ESP in tunnel mode is less problematic.
Steve
[Attachment #3 (text/html)]
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
--></style><title>Re: Why can't ESP authenticate IP
header?</title></head><body>
<div>At 7:11 PM +0530 9/25/01, lokesh wrote:</div>
<blockquote type="cite" cite> <br>
<blockquote>----- Original Message -----</blockquote>
<blockquote><b>From:</b> <a href="mailto:kent@bbn.com">Stephen
Kent</a></blockquote>
<blockquote><b>To:</b> <a
href="mailto:lokeshnb@intotoinc.com">lokesh</a></blockquote>
<blockquote><b>Cc:</b> <a
href="mailto:ipsec@lists.tislabs.com">ipsec@lists.tislabs.com</a></blockquote
>
<blockquote><b>Sent:</b> Tuesday, September 25, 2001 6:13
PM</blockquote>
<blockquote><b>Subject:</b> Re: Why can't ESP authenticate IP
header?</blockquote>
<blockquote><br></blockquote>
<blockquote>At 10:25 AM +0530 9/25/01, lokesh wrote:<br>
<blockquote type="cite" cite>
<blockquote>As noted, ESP coverage of selected header fields would
increase complexity and reduce performance. It also would create even
more circumstances where NAT could interfere with IPsec use. Today,
using ESP in tunnel mode can be made to work with NAT, but if the
outer S/D IP addresses were covered, that capability (I hesitate to
call it a feature) would go away.<br>
</blockquote>
<blockquote> <br>
</blockquote>
<blockquote>Steve,<br>
</blockquote>
<blockquote> <br>
</blockquote>
<blockquote><font face="Arial" size="-1">As for as I know, in
many implementations, NAT is done prior to ipsec processing at the
sending end, and Ipsec processing is done before NAT at the receiving
end.</font><br>
</blockquote>
<blockquote><font face="Arial" size="-1">Are there situvations where
NAT would interfere in ipsec processing ? if so, kindly will you brief
them?</font><br>
</blockquote>
<blockquote> <br>
</blockquote>
<blockquote><font face="Arial" size="-1">Assuming there will be
situations where NAT will interfere with IPsec processing, how AH in
transport mode will work there?</font><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote><br></blockquote>
<blockquote>I get the feeling that you have not been reading this list
for very long.</blockquote>
<blockquote><br></blockquote>
<blockquote>Yes, a combined IPsec/NAT implementation in a security
gateway avoids the problems I cited. The NAT problems I refer to arise
when NAT takes place at a device that is between the IPsec
implementation and the Internet. For example, I am in a hotel room in
London now and if I had IPsec on my laptop, it would have to deal with
the NAT box that the hotel has deployed. Same problem arises in many
cable modem nets, and for desktop IPsec implementations in corporate
environments where NAT is performed at the
gateway/firewall.</blockquote>
<blockquote><br></blockquote>
<blockquote>Steve,</blockquote>
<blockquote> </blockquote>
<blockquote><font face="Arial" size="-1">yes , I have subscribed it
very recently,</font></blockquote>
<blockquote> </blockquote>
<blockquote><font face="Arial" size="-1">in such scenarios, as the one
you mention above, I think AH in transport mode should not be used
right?</font></blockquote>
<blockquote> </blockquote>
<blockquote><font face="Arial" size="-1">Thanks</font></blockquote>
<blockquote><font face="Arial" size="-1">-Lokesh</font></blockquote>
</blockquote>
<div><br></div>
<div>AH in any mode will break in these contexts, as will ESP in
transport mode, but ESP in tunnel mode is less problematic.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic