Subject: RE: [Ipsec] ICMP and MH TSs for IKEv2

From: [email-masked]
Date: Thu, 8 Sep 2005 15:42:22 +0300

Hmm, it seems that I was wrong in my earlier messages about this 
(and the text I wrote for ikev2-clarifications-04 section 4.8 is 
wrong, too -- will be fixed in the next version). Re-reading 
2401bis Section 4.4.1.3 very carefully seems to actually clarify 
this issue.

...except that "Case B" probably has a typo: if the SPD entry
applies both to sending and receiving, the MH message type
(or ICMP type/code) should be in both local and remote port,
right? (Otherwise it's indistinguishable from Case C which 
applies only to sending.)

Best regards,
Pasi

-----Original Message-----
From: ext Stephen Kent [mailto:[email-masked]]
Sent: Thursday, September 08, 2005 9:28 AM
To: Eronen Pasi (Nokia-NRC/Helsinki)
Cc: [email-masked]
Subject: RE: [Ipsec] ICMP and MH TSs for IKEv2

At 10:55 AM +0300 9/7/05, [email-masked] wrote:
Stephen Kent wrote:
> Guys,
>
> We specifically allow asymmetry for ICMP traffic for an SA,
> e.g., so that one can send but not accept traffic for a given
> ICMP message type for an SA. I believe we discussed this issue
> on the list at the time the decision was made, so please do
> not plan to just change by treating it as a clarification.
>
> 2401-bis would also have to change, not just IKEv2.

   I agree that having this kind of asymmetry makes sense in some
   situations (and is very easy to accomplish in 2401-bis). However,
   it's not clear whether IKEv2 can actually negotiate such SAs, since
   it assumes SAs are created in (roughly) symmetrical pairs.

My recollection was that Charlie Lynn provided the text to Charlie
Kaufman to try to ensure that the two specs were compatible. In any
case, 2401-bis makes an explicit statement about the asymmetry, so
irrespective of how IKEv2 thinks of the data it exchanged, IPsec says
how to interpret the received data re local access controls.  In
4.4.1.3 2401-bis says:

        D. To indicate that a system is willing to receive traffic
        with a particular "port" value but NOT send that kind of
        traffic, the system's traffic selectors are set as follows in
        the relevant SPD entry:

           Local's
             next layer protocol = ICMP
             "port" selector     = OPAQUE
           Remote's
             next layer protocol = ICMP
             "port" selector     = <specific ICMP type & code>

            For example, if a security gateway is willing to allow
           systems behind it to send ICMP traceroutes, but is not
           willing to let outside systems run ICMP traceroutes to
           systems behind it, then the security gateway's traffic
           selectors are set as follows in the relevant SPD entry:

           Local's
             next layer protocol = 1 (ICMPv4)
             "port" selector     = 30 (traceroute)

           Remote's
             next layer protocol = 1 (ICMPv4)
             "port" selector     = OPAQUE

This is a pretty explicit description of how to express asymmetry for
exactly this purpose, with an example and rationale.

   (I don't see this as a big problem, though; e.g. 2401-bis allows
   asymmetrical SAs for UDP traffic as well, and IKEv2 doesn't seem to
   support that either.)

Could you clarify the statement that IKEv2 doesn't support this
asymmetry? IKE has two functions re these traffic selectors: it
exchanges them and it interprets them as being acceptable relative to
the SPD. I'd like to think that since 2401-bis defines how the non-IKE
part of IPsec works, that it's definition of how to interpret SPD
entries takes precedence in local processing. I know we lost this
argument last time when we discovered, belatedly, that IKEv2 didn't
have the same semantics for multiple pairs of S/D addresses for an
entry. We modified the 2401-bis text to accommodate IKEv2 because the
needed change was too great, despite the fact that the semantics were
unduly limiting.  I am not inclined to do this again.

   What we're trying to clarify is what exactly the TSi/TSr payloads
   in CREATE_CHILD_SA exchange should contain even in the (presumably
   simpler) case where you want symmetrical treatment for ICMP.

   The reason some kind of clarification is needed is that in
   2401-bis, an SPD entry for ICMP has only one "port" field
   ("OneNextLayerProtocol" element in ASN.1 code of Appendix C).  But
   in IKEv2, both TSi and TSr payloads have port fields, so if we have
   only one value (ICMP type/code or MH type), what to do.

   The obvious solutions seem to be (1) put the one value in TSi
   payload and leave the port in TSr as zero, (2) vice versa, or (3)
   put the same value both to TSi and TSr payloads. IKEv2 spec doesn't
   say which was intended, so some kind of clarification is needed
   (and currently we're leaning towards option 3, although the choice
   doesn't really matter as long as all implementors agree which it
   is).

I agree that clarification on how to translate into IKE payloads is
needed, but the intent in 2401-bis is very clear.

Steve

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