Subject: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00

From: "Peny Yang" <[email-masked]>
Date: Tue, 18 Nov 2008 14:19:05 +0800

Hi,

I just went through the updated WG draft and RFC5077 as well.

In the draft, the new IKE_SESSION_RESUME is defined to present ticket
from client gateway for session resumption.
However, this need to modify IKEv2 base protocol by new messages and
related protection of them. From the implementation point of view, we
do not think this modification is small.
And, when we consider the case that the session resumption can not be
continued by the gateway,  gateway will reject this message. Then, the
regular IKEv2 procedure will be done afterwards. In this case, at
least one round trip is wasted.

Also, I checked RFC 5077 as a reference indicated in the charter. It
just added a SessionTicket extension to the ClientHello message for
ticket presenting from client during session resumption.

Solution:
Add a payload in the IKE INIT message for client to present the index
of ticket to GW. Then if GW can not do the session resumption for some
reason, it just sends the IKE INIT response to clients and starts the
regular IKEv2 initiation procedure. IMHO, this way is more efficient
and flexible.

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

---

From: "Peny Yang" <[email-masked]>
Date: Tue, 18 Nov 2008 20:30:39 +0800

Hi,

Solution:

Peny

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 18 Nov 2008 22:15:09 +0200

> do not think this modification is small.

As an IKEv2 implementor I think having separate IKE_SESSION_RESUME
exchange actually makes the changes easier to do, than to go and
modify the existing IKE_SA_INIT AND IKE_SA_AUTH state machines. The
state machines of the IKE_SA_INIT and especially IKE_SA_AUTH are
already quite complicated because of the EAP, and other options and
especially even more when someone starts to implement things like
RFC4739 in which case the state machine and especially the policy gets
extremely complicated...

> least one round trip is wasted.

Yes, but I do not think that case is that common case. I think the
most common case will be the case when gateway still has the ticket
and will accept it, thus we need to optimize for it. If the gateway do
not have ticket anymore, that means we need to do Diffie-Hellman,
which quite often takes more time than the one round trip. 

> regular IKEv2 initiation procedure. IMHO, this way is more efficient

Note, that in this case the client needs to do Diffie-Hellman setup
before it can even see if the server has ticket still valid or not.
This will waste resources on the client, and will consume power and so
on in the mobile devices. Also the packets gets quite big, as they
need to include all things that can be in the IKE_SA_INIT (i.e. KE
payload etc), and the ticket itself, and also some encrypted
information to proof that client do have the keying material still. So
the minimum version of that packet would look like:

   HDR, SAi1, KEi, Ni, N(TICKET_OPAQUE), SK { IDi } ->

Hmm... the draft does not actually say, but I think the current idea
is that all IPsec SAs are removed when resumption happens, and they
need to be rekeyed, which is why the current IKE_SESSION_RESUME
exchange has payloads required for the one child sa creation, i.e.
where the first packet would be:

   HDR, SAi1, KEi, Ni, N(TICKET_OPAQUE),
	SK { IDi, [IDr,] SAi2, TSi, TSr, CP(...) }

so its starts to get quite large. Note, that it now also has two SA
payloads and so on, which will again add more complications as
implementations must keep in mind which SA payload was outside the
encryption and which inside etc.

Now if the ticket is still valid, then client has wasted its cpu
resources by calculating the Diffie-Hellman value it sent in as KEi,
the bandwidth between the peers was wasted by sending SAi1, and KEi
payloads (KEi is the largest payload in normal exchange).

I think the current approach in the draft is better and simplier.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Peny Yang" <[email-masked]>
Date: Wed, 19 Nov 2008 06:16:38 +0800

Hey, Tero:

> RFC4739 in which case the state machine and especially the policy gets
[Peny] Basically, I don't think extending IKE_SA_INIT is more
complicated than IKE_SESSION_RESUME.
One thing for sure, IKE_SESSION_RESUME also need to add new states in
the state machine of IKEv2. And, to implement the IKE_SESSION_RESUME,
I must make more codes to protect these messages.
And, If the extensions of IKEv2-EAP and RFC4739 are supported, these
procedure will be done right after the IKE_SA_INIT procedure has been
finished. So, the extension of IKE_SA_INIT in my mind will not be
interleaved with IKEv2-EAP/RFC4739 procedures at all. And by extending
the IKE_SA_INIT, we don't need to design new way to protect the
messages.
So, I am in favor of using IKE_SA_INIT extension to support session
resumption, which IMHO is easier to implement.

> which quite often takes more time than the one round trip.
[Peny] Well, it seems you assume the case of ticket-by-reference. Basically, I
agree that the time of one round trip may be shorter than DH. But, we have the
solution to save that round trip in this case. Why don't we just do it.

> before it can even see if the server has ticket still valid or not.
[Peny] I am confused here. Are you talking about the case of
ticket-by-reference or the one of ticket-by-value.
For the former one, ticket is on server side. But I don't think the
client need to do DH, if the ticket is valid. KEi can be retrieved
from client local IKE_SA before session resumption. If ticket on
server is not valid in this case, server just fall back to the regular
IKEv2 procedure with DH.
For the latter one, server does not have the ticket before the session
resumption.

> Also the packets gets quite big, as they
> so its starts to get quite large.
[Peny] Agree. I think the ticket should be very small.

> Note, that it now also has two SA
[Peny] Yeah. I asked this question this morning.

> payloads (KEi is the largest payload in normal exchange).
[Peny] Client can retrieve the KEi from local storage.

Regards,
Peny

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 19 Nov 2008 17:59:08 +0200

> complicated than IKE_SESSION_RESUME.

Then we disagree on this point, but I do not think it is productive to
waste too much time for this point. 

> interleaved with IKEv2-EAP/RFC4739 procedures at all.

True, I just wanted to point out that the current state machine is
already quite complicated, and I would not like to make it any more
complicated than it is now.

> And by extending

Not true, as IKE_SA_INIT does not have any protection as such, the
contents of it is protected by the AUTH payload in IKE_AUTH exchange.
There is no encrypted part in that, and in normally does not even have
crypto context at that point. Adding encrypted SK {} part is designing
new way to protect the mssages.

> [Peny] Well, it seems you assume the case of ticket-by-reference.

I didn't really assume either one of those, as it does not matter.
With ticket-by-reference the ticket would be so small that putting it
to IKE_SA_INIT, but for ticket-by-value the actual ticket might be
quite large. 

> Basically, I agree that the time of one round trip may be shorter
> than DH. But, we have the solution to save that round trip in this
> case. Why don't we just do it.

Because DH is much more expensive than round trip, and in most common
case there would not be extra round trip at all, as ticket is
accepted. 

> ticket-by-reference or the one of ticket-by-value.

Both. It does not matter whether ticket-by-reference or
ticket-by-value is used, if the resumption is done part of IKE_SA_INIT
the client MUST do Diffie-Hellman setup and generate the KEi payload
which is part of the same message, just in case.

> from client local IKE_SA before session resumption.

KEi cannot be retrieved, as it is not present in client anymore, and
you do NOT want to reuse the exponential that was used few hours ago
when the original IKE SA was created. The KEi would need to be new and
client would need to do the calculation. The KEi in the IKE_SA_INIT
does not have anything to do with the old IKE SA, it might even be
over different Diffie-Hellman group. 

> [Peny] Agree. I think the ticket should be very small.

The minimum ticket-by-value size is around 128, and I guess it will be
around 200 bytes normally (assuming ticket format from Appendix A). 

> [Peny] Client can retrieve the KEi from local storage.

You do assume that crypto library allows exponent reuse. Some crypto
libraries do not allow that, they will erase all information about the
Diffie-Hellman pieces when the Diffie-Hellman calculation is finished.
Actually security considerations section of RFC 4306 does assume that:

   It is assumed that all Diffie-Hellman exponents are erased from
   memory after use.  In particular, these exponents MUST NOT be derived
   from long-lived secrets like the seed to a pseudo-random generator
   that is not erased after use.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "He, Wenxiao" <[email-masked]>
Date: Thu, 20 Nov 2008 00:34:42 +0000

Hello,

I am trying to figure out the requirements of processing ICMP error message as an IPsec end host.

Just googled and noticed that there was a discussion (took place on Tue, 31 Jul 2007) on ICMP topic but focusing on gateway. The original discussion is copied at the end of this message.

Now, consider a simple end-to-end case between host A and host B. The SPD between A and B only specifies a SA for UDP, and there is no SPD to cover ICMP traffic. When host A sends a UDP message to host B, a SA pair is negotiated. And the A->B UDP message triggers host B to send back an ICMP error message.

A) If I apply section 6.2 "Processing Protected, Transit ICMP Error Messages" to the B->A ICMP error message, the icmp error message will be carried by the extant SA pair generated by UDP message.

B) If I donot apply the process specified in section 6.2, then the ICMP ERROR message will be discarded because no SPD is found.

Which of the above two approaches is the expected behavior for an IPsec end host? Does section 6 apply to IPsec end host?

Thanks,
Wenxiao He

==========================================

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ipsec] RFC 4301 and ICMP processing

    * To: Stephen Kent <kent at bbn.com>
    * Subject: Re: [Ipsec] RFC 4301 and ICMP processing
    * From: Scott C Moonen <smoonen at us.ibm.com>
    * Date: Tue, 31 Jul 2007 16:08:18 -0400
    * Cc: ipsec at ietf.org
    * In-reply-to: <p06240513c2d5398829fc@[128.89.89.71]>
    * List-help: <mailto:[email-masked]?subject=help>
    * List-id: IP Security <ipsec.ietf.org>
    * List-post: <mailto:[email-masked]>
    * List-subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:[email-masked]?subject=subscribe>
    * List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:[email-masked]?subject=unsubscribe>

Thanks for the very quick response, Stephen!

Scott Moonen (smoonen at us.ibm.com)
http://scott.andstuff.org/

Stephen Kent <kent at bbn.com>

07/31/2007 03:44 PM

To
        Scott C Moonen/Raleigh/IBM at IBMUS
cc
        ipsec at ietf.org
Subject
        Re: [Ipsec] RFC 4301 and ICMP processing

At 11:52 AM -0600 7/31/07, Scott C Moonen wrote:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
      micalg=sha1; boundary=-------z66_boundary_sign

In section 6.2, RFC 4301 requires the use of additional checks to verify whether an ICMP packet is consistent with an SA's selectors.  When sending or receiving an ICMP packet, if there is no existing SA or SPD entry to match the ICMP error, then the ICMP packet is allowed to traverse the same SA that its embedded packet would have traversed.

It is reasonably clear what is to be done for an end-to-end SA, but the RFC's language is unclear as to whether this is required for a gateway SA.  Consider the following setup:

       H1 ----- GW1 ===== GW2 ----- RTR1 ----- H2
Host H1 sends a UDP packet to H2 that is encapsulated in an IPsec tunnel between gateways GW1 and GW2.  My question is this: If RTR1 originates an ICMP error for this packet that traverses the same path in reverse, should GW2 encapsulate the ICMP packet in the original UDP SA (in the absence of other rules for carrying the ICMP packet), and should GW1 allow the encapsulated ICMP packet to arrive over that UDP SA?

4301 allows GW1 and GW2 to handle this situation in either of two ways. An SPD can say that the SA for the H1/H2 traffic ALSO can carry ICMP messages, or the SPD can call for creating a separate SA between the two GWs to carry only ICMP messages. So, the answer to your question depends on the contents of the SPDs at GW1 and GW2.

In the case of GW1 allowing the ICMP packet to exit the tunnel and be forwarded, the RFC hints strongly that this should be the case.  The last sentence of section 6.2 speaks of cases where the ICMP must not be forwarded,

The intent of the last sentence in 6.2 is to emphasize that if an ICMP packet is received on an inbound SA and cannot be verified via the procedure outlined in 6.2, then it MUST be discarded, not forwarded. Section 6.2 does not express a strong preference for either of the approaches to carriage of ICMP traffic defined in this section. Compliant implementations MUST support both approaches, e.g., the text says "To accommodate both policies, ..." .

 strongly implying that GW1 is normally expected to forward in this case.  But it is less clear that GW2 should encapsulate ICMP errors in non-ICMP SAs for errors that it has not originated.  Section 6.2 speaks only of performing this encapsulation for "outbound" ICMP errors, and of ICMP errors "sent and received via SAs."  What if GW2 is doing forwarding but not sending?

The ICMP errors are outbound whether they are generated by the security gateway or by a host or router behind the SG. So whether the GW is generating the ICMP error message itself, or forwarding it, the treatment is the same at this stage of processing.

I'm inclined to think that GW2 should encapsulate any ICMP error according to these rules, even routed ICMP errors which it did not itself originate.

That's controlled by the SPD.

 This is parallel with the fact that GW1 seems to be expected to behave in the reverse manner, and also aligns with the use of "outbound" at other points in the RFC to be inclusive of forwarded traffic.  The one concern I can see is that ICMP errors that GW2 did not originate are considered less trustworthy and we may not wish to apply this processing to them.  However, it is possible to prevent this by creating additional SPD entries at GW2 to prevent untrustworthy ICMP errors from entering the gateway in the first place.

yes, the GW could elect to not forward ICMP traffic from routers behind it, for security reasons.

Am I correct in assuming that section 6.2 of RFC 4301 is intended to address both local and forwarded ICMP traffic?  Or is the treatment of forwarded traffic left to the discretion of each implementation?

As I noted above, the intent of 6.2 is to accommodate both locally generated and forwarded ICMP traffic.

Steve

_______________________________________________
Ipsec mailing list
Ipsec at ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

    * References:
          o Re: [Ipsec] RFC 4301 and ICMP processing
                + From: Stephen Kent

    * Prev by Date: Re: [Ipsec] RFC 4301 and ICMP processing
    * Next by Date: Re: Re: [Ipsec] RFC 4301 and ICMP processing
    * Previous by thread: Re: [Ipsec] RFC 4301 and ICMP processing
    * Next by thread: Re: Re: [Ipsec] RFC 4301 and ICMP processing
    * Index(es):
          o Date
          o Thread

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Peny Yang" <[email-masked]>
Date: Thu, 20 Nov 2008 23:36:12 +0800

Hi, Tero:

Please check the lines:

> waste too much time for this point.
[Peny] Fine.

> complicated than it is now.
[Peny] Yeah. It's already complicated. But, some states need to be
added, no matter we add new IKE_SESSION_RESUME or extend the
IKE_SA_INIT. Do you have any good idea to avoid the modification of
IKEv2 state machine?

> new way to protect the mssages.
[Peny] You are right. In my opinion, the SK{} part is not necessary to
present the ticket.

> to IKE_SA_INIT, but for ticket-by-value the actual ticket might be
[Peny] Thanks. You agree with us.

> case there would not be extra round trip at all, as ticket is
[Peny] Firstly, I do not agree that DH is ALWAYS much more expensive
than round trip. In some circumstances, such as in the wireless
network with limited uplink, a round trip may be longer.

> which is part of the same message, just in case.
[Peny] I don't think it's a MUST to redo DH on client for session
resumption. For regular IKEv2 session setup, the DH need to be done
every time.  For Session resumption, the KEi can be reused.

> over different Diffie-Hellman group.
[Peny] For session resumption, it will not be over different DH group.

> You do assume that crypto library allows exponent reuse.
[Peny] Yes, I do assume reusing KEi on client.

> Some crypto libraries do not allow that, they will erase all information
> about  the
[Peny] Well, basically, I agree that DH exponentiations will not be
used for a long time according to RFC4306. However, I don't think RFC
4306 assumes to erase the DH exponentiations after the CALCULATION is
finished. It just said the DH exponent is assumed to be erased after
USE. If we need to USE it in the session resumption, I think RFC4306
does not oppose us from using it before the renewing of DH exponent.
And, RFC4306 does not set the limit on reusing the DH exponentiations,
as well. The extension of IKE_SA_INIT just uses the renewed DH
exponent once during the session resumption. And in session
resumption, it will not fall into different DH exchange group of
previous DH exchange. Personally, I don't encourage using DH exponents
for a long time. But, it's worthy to re-using it for the infrequent
session resumption.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Nov 2008 18:54:25 +0200

> IKE_SA_INIT. Do you have any good idea to avoid the modification of

One of the main points is to keep the implementation separate, so we
can easily make version that does not support it if customer wants so.
Adding lots of ifdefs around gets code very messy, it is much easier
to have separate state machine part for the IKE_SESSION_RESUME.
Modular design is good thing... 

> [Peny] You are right. In my opinion, the SK{} part is not necessary to

The whole security of the resumption comes from that part, as it is
only thing that proofs that the client actually was part of the IKE SA
before, and knows the SK_d which used to create the keying material
used to protect SK_D. 

> [Peny] Yes, I do assume reusing KEi on client.

I do know that our crypto library does not allow doing that (unless we
specifically add support for that)... so we would have to recalculate
the KEi every time. I think one of the reasons for that was related to
FIPS certificate, but don't remember exactly.

> for a long time. But, it's worthy to re-using it for the infrequent

I would still prefer separate IKE_SESSION_RESUME exchange than
combining everything to the IKE_SA_INIT. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Peny Yang" <[email-masked]>
Date: Fri, 21 Nov 2008 01:37:17 +0800

> Modular design is good thing...
[Peny] Then we disagree on this point. Well, it's hard to judge at
this moment. IMHO, adding 1 (at most two depending on the state
operation) state in the state machine is not a big deal at all for the
implementation. Anyhow, it's not so productive to debate on this point
any more.

> before, and knows the SK_d which used to create the keying material
[Peny] I don't think the client has to proof to be part of previous
IKE SA by this way. SK_d can be found by reference or be inside the
ticket. Server side can cross check the information in the IKE_SA_INIT
with the content referenced/stored by ticket, as well.

> FIPS certificate, but don't remember exactly.
[Peny] At least some open source implementation already can simply
store the DH exponent for a while before next renew of DH.

> combining everything to the IKE_SA_INIT.
[Peny] Well, all the implementations have different perspectives.
Anyhow, if there are the requirements to extend the existed messages
for flexibility and efficiency, IMHO, we would need to support that.

Peny

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Nov 2008 21:07:38 +0200

> with the content referenced/stored by ticket, as well.

It is mandatory to verify that one sending the ticket for resumption
actually knows the SK_d too. Otherwise attacker who knows the ticket
(for example have seen it sent by legitimate client when it tried to
resumption) can send it to server and trigger server to think he has
IKE SA up and running, without being part of the previous exchange.
This would also cause the server to mark ticket as used and that would
remove the original client the ability to use it anymore.

I think the SK_d is mandatory there for the security of the protocol. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Peny Yang" <[email-masked]>
Date: Fri, 21 Nov 2008 03:43:21 +0800

> I think the SK_d is mandatory there for the security of the protocol.
[Peny] Ticket is only valid for one time use. Some attacker has seen
it from the legitimate client, the ticket is no longer useful after
resumption.

Peny

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Nov 2008 22:59:18 +0200

> it from the legitimate client, the ticket is no longer useful after

Attacker might have seen it when the client tried to do resumption but
could not because the network was still down, or attacker can take the
ticket from the client's valid resumption message, change the SPIi and
send it to server before client's message gets there, and that will
cause the ticket to be invalid when client's message comes there.
Which actually says that the SPIi of the resumption message needs to
be authenticated, thus the SK_d is required to cover the whole IKE
message. Also attacker can see the ticket if server decides to use
cookie requests. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 20 Nov 2008 13:18:30 -0800

Indeed!

Lakshminath

---

From: "Peny Yang" <[email-masked]>
Date: Fri, 21 Nov 2008 06:37:16 +0800

> could not because the network was still down,
[Peny] Excuse me, what's the meaning of "network was done"? Do you
mean the server was still down?
> or attacker can take the
[Peny] Please let me clarify it firstly. In all of the cases above,
when attackers can see the ticket, it can get other things (new SPIi
in the HDR and SK{}), as well. So, in this sense, how could the server
authenticate the SPIi with ticket and SK { IDi } (minimum version as
you said)?

Peny

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 21 Nov 2008 00:44:52 +0200

> mean the server was still down?

Either one. If the attacker can fool the client to think the server is
down by breaking the network link between them, that is enough to
trigger the client to do resumption. 

> authenticate the SPIi with ticket and SK { IDi } (minimum version as

Because only client who knows the SK_d can calculate SK {} which has
MAC of the full packet. So attacker cannot modify anything in the
packet without server detecting it, if the ticket is still valid. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Peny Yang" <[email-masked]>
Date: Fri, 21 Nov 2008 07:03:47 +0800

> packet without server detecting it, if the ticket is still valid.
[Peny] OK, Agree. Well, what if the IKE_SA_INIT message is extended by
adding SK{} only for session resumption ?

Peny

---

From: "He, Wenxiao" <[email-masked]>
Date: Mon, 24 Nov 2008 19:10:24 +0000

Hi,

Anyone has an opinion on processing ICMP error message as an IPsec end host?

Thanks,
Wenxiao

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of He, Wenxiao
> Sent: Wednesday, November 19, 2008 4:35 PM
> To: [email-masked]
> Subject: Re: [IPsec] [Ipsec] RFC 4301 and ICMP processing
>
>
> Hello,
>
> Just googled and noticed that there was a discussion (took
> place on Tue, 31 Jul 2007) on ICMP topic but focusing on
> gateway. The original discussion is copied at the end of this message.
>
> Now, consider a simple end-to-end case between host A and
> host B. The SPD between A and B only specifies a SA for UDP,
> and there is no SPD to cover ICMP traffic. When host A sends
> a UDP message to host B, a SA pair is negotiated. And the
> A->B UDP message triggers host B to send back an ICMP error message.
>
> A) If I apply section 6.2 "Processing Protected, Transit ICMP
> Error Messages" to the B->A ICMP error message, the icmp
> error message will be carried by the extant SA pair generated
> by UDP message.
>
> B) If I donot apply the process specified in section 6.2,
> then the ICMP ERROR message will be discarded because no SPD is found.
>
> Which of the above two approaches is the expected behavior
> for an IPsec end host? Does section 6 apply to IPsec end host?
>
> Thanks,
> Wenxiao He
>
>     * List-subscribe:
> <https://www1.ietf.org/mailman/listinfo/ipsec>,
> <mailto:[email-masked]?subject=subscribe>
>     * List-unsubscribe:
> <https://www1.ietf.org/mailman/listinfo/ipsec>,
> <mailto:[email-masked]?subject=unsubscribe>
>
>
>         Scott C Moonen/Raleigh/IBM at IBMUS cc
>         ipsec at ietf.org
> Subject
> Content-Type: multipart/signed;
> protocol="application/x-pkcs7-signature";
> In section 6.2, RFC 4301 requires the use of additional
> checks to verify whether an ICMP packet is consistent with an
> SA's selectors.  When sending or receiving an ICMP packet, if
> there is no existing SA or SPD entry to match the ICMP error,
> then the ICMP packet is allowed to traverse the same SA that
> its embedded packet would have traversed.
>
> It is reasonably clear what is to be done for an end-to-end
> SA, but the RFC's language is unclear as to whether this is
> required for a gateway SA.  Consider the following setup:
>
>        H1 ----- GW1 ===== GW2 ----- RTR1 ----- H2 Host H1
> sends a UDP packet to H2 that is encapsulated in an IPsec
> tunnel between gateways GW1 and GW2.  My question is this: If
> RTR1 originates an ICMP error for this packet that traverses
> the same path in reverse, should GW2 encapsulate the ICMP
> packet in the original UDP SA (in the absence of other rules
> for carrying the ICMP packet), and should GW1 allow the
> encapsulated ICMP packet to arrive over that UDP SA?
>
> 4301 allows GW1 and GW2 to handle this situation in either of
> two ways. An SPD can say that the SA for the H1/H2 traffic
> ALSO can carry ICMP messages, or the SPD can call for
> creating a separate SA between the two GWs to carry only ICMP
> messages. So, the answer to your question depends on the
> contents of the SPDs at GW1 and GW2.
>
> In the case of GW1 allowing the ICMP packet to exit the
> tunnel and be forwarded, the RFC hints strongly that this
> should be the case.  The last sentence of section 6.2 speaks
> of cases where the ICMP must not be forwarded,
>
> The intent of the last sentence in 6.2 is to emphasize that
> if an ICMP packet is received on an inbound SA and cannot be
> verified via the procedure outlined in 6.2, then it MUST be
> discarded, not forwarded. Section 6.2 does not express a
> strong preference for either of the approaches to carriage of
> ICMP traffic defined in this section. Compliant
> implementations MUST support both approaches, e.g., the text
> says "To accommodate both policies, ..." .
>
>  strongly implying that GW1 is normally expected to forward
> in this case.  But it is less clear that GW2 should
> encapsulate ICMP errors in non-ICMP SAs for errors that it
> has not originated.  Section 6.2 speaks only of performing
> this encapsulation for "outbound" ICMP errors, and of ICMP
> errors "sent and received via SAs."  What if GW2 is doing
> forwarding but not sending?
>
> The ICMP errors are outbound whether they are generated by
> the security gateway or by a host or router behind the SG. So
> whether the GW is generating the ICMP error message itself,
> or forwarding it, the treatment is the same at this stage of
> processing.
>
> I'm inclined to think that GW2 should encapsulate any ICMP
> error according to these rules, even routed ICMP errors which
> it did not itself originate.
>
>  This is parallel with the fact that GW1 seems to be expected
> to behave in the reverse manner, and also aligns with the use
> of "outbound" at other points in the RFC to be inclusive of
> forwarded traffic.  The one concern I can see is that ICMP
> errors that GW2 did not originate are considered less
> trustworthy and we may not wish to apply this processing to
> them.  However, it is possible to prevent this by creating
> additional SPD entries at GW2 to prevent untrustworthy ICMP
> errors from entering the gateway in the first place.
>
> Am I correct in assuming that section 6.2 of RFC 4301 is
> intended to address both local and forwarded ICMP traffic?
> Or is the treatment of forwarded traffic left to the
> discretion of each implementation?
>
> As I noted above, the intent of 6.2 is to accommodate both
> locally generated and forwarded ICMP traffic.
>
> Steve
>
> Note: Messages sent to this list are the opinions of the
> senders and do not imply endorsement by the IETF.

---

From: Dan McDonald <[email-masked]>
Date: Mon, 24 Nov 2008 14:28:37 -0500

> > A->B UDP message triggers host B to send back an ICMP error message.

So far, so good.

> > for an IPsec end host? Does section 6 apply to IPsec end host?

I can't say what everyone else does, but in {,Open}Solaris we've always had
ICMP errors reflect back with the same policy (and SA) used by the traffic.
It makes sense from a not-leaking-information point-of-view.

In fact, you've helped me find a bug with inbound ICMP processing -- if an SA
is tied to a protocol or port, ICMP SPD checking needs to apply the *inner*
packet selectors.

Dan