About transport mode, true enough, and see also 4891 for an IPv6 flavor.

But transport mode is not the reason for AH. These things could easily
have avoided transport mode.

In IPv4, the place to look for different functionality with AH is to
look away from unicast to multicast and perhaps anycast.

Rich Graveman

On Mon, Nov 14, 2011 at 5:55 PM, Yoav Nir <y...@checkpoint.com> wrote:
> What Paul said, mostly, but see below.
>
> On Nov 15, 2011, at 2:39 AM, Paul Wouters wrote:
>
>> On Sun, 13 Nov 2011, Vilhelm Jutvik wrote:
>>
>>>> From page 62, RFC 4301:
>>>
>>> ...
>>> 4.  Apply AH or ESP processing as specified, using the SAD entry
>>>   selected in step 3a above.  Then match the packet against the
>>>   inbound selectors identified by the SAD entry to verify that the
>>>   received packet is appropriate for the SA via which it was
>>>   received.
>>> ...
>>>
>>> This, if true, would imply that all functionality offered by AH could
>>> be provided by ESP. Is this true?
>>
>> I agree. The people who prefer transport mode usually mutter something about
>> a few saved bytes and how that is better for the MTU. But tunnel mode works
>> much better through NAT then transport mode, which needs ackward hacks that
>> are all vendor-specific. ESP-null is basically the equivalent of AH. It has
>> been about a decade now that Ferguson and Scheier said to get rid of AH and
>> transport mode altogether - as a result of which FreeS/WAN 2.05 was released
>> that removed support for it.
>>
>> See further: http://www.schneier.com/paper-ipsec.pdf
>
> FreeS/WAN did eliminate transport mode, but that project is dead. The project 
> that is active now (strongSwan) does have it.
>
> RFC 3191 (L2TP over IPsec) says that transport mode MUST be supported for 
> L2TP over IPsec. That, and the fact that this is the way Microsoft 
> implemented their L2TP client is the reason why most gateway vendors have 
> implemented transport mode. That and the fact that Cisco like to encrypt 
> their GRE tunnels in transport mode.
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to