Subject: RE: [IPsec] IPSec, ESP and AH authentication

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 10 Oct 2007 10:22:40 -0700 (GMT-07:00)

I guess my IPv6 ignorance is showing (again), and I'd better get busy and remedy that.

Are you saying that despite the anti-replay capability of IPsec, the payloads of the packets you describe below can be replayed, and this will have destructive consequences for the intervening infrastructure?

My guess is that this is complex, and that lots of people here won't want to be bored simply due to my ignorance. If you know of docs I could read (especially brief ones :-)) to better understand the issues here, maybe you can send me pointers offline.

Thanks for the clarification.

-----Original Message-----
>From: "Dunn, Jeffrey, CTR, OASD(HA)/TMA" <[email-masked]>
>Sent: Oct 10, 2007 9:56 AM
>To: "Scott G. Kelly" <[email-masked]>, Tjeu <[email-masked]>
>Cc: [email-masked], "Dunn, Jeffrey, CTR, OASD(HA)/TMA" <[email-masked]>
>Subject: RE: [IPsec] IPSec, ESP and AH authentication
>
>Scott,
>
>While data origin is IP (v4 or v6) address agnostic from the point of
>view of user data, e.g., e-mail, it can be important to routing
>protocols.  This is especially true for IPv6, where the OSPFv3 router ID
>is no longer an IP (v4) address, it is just a 32 bit unsigned integer.
>As a result, ESP-Null authenticated packets can be re-played with a
>different source IPv6 address.  This will cause some obvious and nasty
>problems.  Putting IPv6 addresses in the SPD will, of course, mitigate
>this problem, but with a 16 octet IPv6 address, this is cumbersome and
>error prone.  As a result, it is more expedient to use AH.
>
>
>Best Regards,
>
>Jeffrey Dunn
>
>
>-----Original Message-----
>From: Scott G. Kelly [mailto:[email-masked]] 
>Sent: Wednesday, October 10, 2007 11:39 AM
>To: Tjeu
>Cc: [email-masked]
>Subject: Re: [IPsec] IPSec, ESP and AH authentication
>
>As Srinivasa points out, changes to the source IP really are irrelevant.
>Data origin authentication has nothing to do with IP addresses - it has
>to do with _endpoints_, which may be applications, people, etc. 
>
>IP addresses can change, but presumably, only the authorized,
>authenticated endpoint has the appropriate keys with which to assert the
>originating identity.
>
>-----Original Message-----
>>From: ns srinivasa murthy <[email-masked]>
>>Sent: Oct 10, 2007 12:47 AM
>>To: "Steven M. Bellovin" <[email-masked]>, Tjeu 
>><[email-masked]>
>>Cc: [email-masked]
>>Subject: Re: [IPsec] IPSec, ESP and AH authentication
>>
>>
>>In tunnel mode ESP ,the inner IP header is protected and as such no one
>
>>can change the source IP in between.This inner IP packet is the actual 
>>data packet and its source IP can not be changed.So Data origin 
>>Authentication is supported in tunnel mode ESP.
>>
>>Even if the outer Source IP is changed in between,the attacker can not 
>>do any harm.The implementation has to take care that the out going ESP 
>>traffic is sent only to the tunnel end point detected as part of IKE 
>>negotiation.
>>
>>-nsmurthy
>>
>>At 05:13 AM 10/10/2007, Steven M. Bellovin wrote:
>>>On Tue, 9 Oct 2007 06:26:57 -0700 (PDT) Tjeu 
>>><[email-masked]> wrote:
>>>
>>> >
>>> > Dear All,
>>> >
>>> > As you might know, IPSec ESP authentication does not authenticate 
>>> > the destination and source addresses of the IP header, whereas the 
>>> > IPSec AH authentication does(i.e. calculatec MAC over them). 
>>> > However, both claim that they offer data origin authentication. It 
>>> > is not clear for me how the ESP authentication offers data origin 
>>> > authentication, as the MAC is not computed on the source and dest 
>>> > addresses. Therefore the attacker could easily modify them. Am I 
>>> > missing something ? I would be thankful if anyone could provide 
>>> > links where I could read regarding this subject, in more details. I
>
>>> > looked through some RFC's but they dont seem to help.
>>> >
>>>Put the IP addresses in the SPD, and derive that in turn from the 
>>>authenticated identity.  If the attacker modifies them, the packet 
>>>will be dropped because it won't match the SPD.
>>>
>>>
>>>                 --Steve Bellovin, http://www.cs.columbia.edu/~smb
>>>
>>>
>>>_______________________________________________
>>>IPsec mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/ipsec
>>
>>
>>***********************************************************************
>>********* This email message (including any attachments) is for the 
>>sole use of the intended recipient(s) and may contain confidential, 
>>proprietary and privileged information. Any unauthorized review, use, 
>>disclosure or distribution is prohibited. If you are not the intended 
>>recipient, please immediately notify the sender by reply email and
>destroy all copies of the original message.
>>Thank you.
>> 
>>Intoto Inc. 
>>
>
>
>
>_______________________________________________
>IPsec mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Paul Koning <[email-masked]>
Date: Wed, 10 Oct 2007 13:45:43 -0400

>>>>> "Scott" == Scott G Kelly <[email-masked]> writes:

 Scott> I guess my IPv6 ignorance is showing (again), and I'd better
 Scott> get busy and remedy that.  Are you saying that despite the
 Scott> anti-replay capability of IPsec, the payloads of the packets
 Scott> you describe below can be replayed, and this will have
 Scott> destructive consequences for the intervening infrastructure?

 Scott> My guess is that this is complex, and that lots of people here
 Scott> won't want to be bored simply due to my ignorance. If you know
 Scott> of docs I could read (especially brief ones :-)) to better
 Scott> understand the issues here, maybe you can send me pointers
 Scott> offline.

Please don't move this offline.  I'm puzzled too by this assertion
that antireplay doesn't work.  Or was the comment addressed to the
privacy-only mode of ESP (no authentication)?  

IPsec is an end to end protocol; how is it possible for the behavior
of the routers to have any bearing on what services you get from
IPsec?

	paul

---

From: "Dunn, Jeffrey, CTR, OASD(HA)/TMA" <[email-masked]>
Date: Wed, 10 Oct 2007 13:52:43 -0400

Scott,

Not a problem.  My argument is based on some fairly simple logic and the
following.  RFC 4552 states:

"The SPD selection function MUST return an SPD with the following
   rules for all the interfaces that have OSPFv3
   authentication/confidentiality enabled.

      No.  source       destination       protocol        action
      2   fe80::/10        any             OSPF           protect
      3   fe80::/10        any       ESP/OSPF or AH/OSPF  protect"

This is specifically to support multicast links (AllSPFRouters or
AllDRouters).  Since anti-replay (sequence number processing) is not
supported for multicast, there is no anti-replay for some OSPFv3 using
multicast links.  Specifically, RFC 4303 states:

"ESP provides no means of synchronizing packet counters among multiple
senders or meaningfully managing a receiver packet counter and window in
the context of multiple senders.  Thus, for a multi-sender SA, the
anti-replay features of ESP are not available."

As a result, IMHO, any OSPFv3 router using multicast links probably
should be using AH rather than ESP-Null.

Best Regards,

Jeffrey Dunn

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2007 1:23 PM
To: Dunn, Jeffrey, CTR, OASD(HA)/TMA; Tjeu
Cc: [email-masked]
Subject: RE: [IPsec] IPSec, ESP and AH authentication

I guess my IPv6 ignorance is showing (again), and I'd better get busy
and remedy that.

Are you saying that despite the anti-replay capability of IPsec, the
payloads of the packets you describe below can be replayed, and this
will have destructive consequences for the intervening infrastructure?

My guess is that this is complex, and that lots of people here won't
want to be bored simply due to my ignorance. If you know of docs I could
read (especially brief ones :-)) to better understand the issues here,
maybe you can send me pointers offline.

-----Original Message-----
>protocols.  This is especially true for IPv6, where the OSPFv3 router 
>ID is no longer an IP (v4) address, it is just a 32 bit unsigned
integer.

>authenticated endpoint has the appropriate keys with which to assert 
>the originating identity.
>

---

From: Charlie Kaufman <[email-masked]>
Date: Wed, 10 Oct 2007 22:08:03 -0700

Paul Koning [mailto:[email-masked]] writes:

>IPsec is an end to end protocol; how is it possible for the
>behavior of the routers to have any bearing on what services
>you get from IPsec?

It doesn't relate to routers. It relates to multicast, and the example of multicast someone brought up involved communications between routers.

Using IPsec to secure multicast has never actually been specified, though various specs include hints about how things might work. Key distribution for multicast is an active research topic.

If one were actually to use IPsec to secure multicast, the most plausible way to do it would be to have a different SPI for each sender. If multiple senders share an SPI, you end up with the problem the original poster brought up (that a man in the middle could change the source address from one legitimate sender to another and when using ESP in transport mode this would not be detectable). You also end up with the problem that you can't detect replayed packets because there would be no way for the various senders to keep their sequence numbers in sync (hence two legitimate senders could send different packets with the same sequence number and recipients would have to process both of them).

It will be interesting to see if anyone ever actually uses IPsec for multicast, and if so how they will address the hard problems. (I could imagine a spec that says manually distribute keys and ignore sequence numbers, but deploying such a system securely seems hard to imagine).

        --Charlie