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

From: [email-masked]
Date: Wed, 7 Sep 2005 10:55:50 +0300

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.

(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.)

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).

Best regards,
Pasi

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Sep 2005 18:06:24 +0200

In your previous mail you wrote:

=> in fact there is a real issue about what means symmetrical in
this context...

=> where is it in the 2401-bis?

=> I agree but if we can solve the asymmetrical case too...

=> IMHO this OneNextLayerProtocol specifies explicitely symmetrical case.

   
=> for the asymmetrical case we can imagine a (4) with the value for
traffic from local to remote in the local port and the value for
the other way in the remote port. This makes more sense for Mobility
where traffics are known to be always asymmetrical!

Thanks

[email-masked]

PS: BTW both IKEv2 and RFC 2401bis should be updated about this point.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Sep 2005 02:27:56 -0400

>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.

>asymmetrical SAs for UDP traffic as well, and IKEv2 doesn't seem

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.

>the choice doesn't really matter as long as all implementors

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

Steve

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 14:34:04 +0200

Local's
   
=> this is fine:
 - we know how to express asymmetry for ICMP in 2401-bis
 - we can derive what to put in IKEv2 TSs
But IMHO there are some small details to fix:
 - what is the difference between B and C?
 - remove the local in "the 16-bit local "port" selector." for MH, 4.4.1.1
 - should B mention that C and D are valid options (i.e., MH and ICMP
   are handled the same way)?

=> as soon as 2401-bis will be really "very clear" I believe the
clarification will be "very easy".

Thanks

PS: BTW what is the first/second in AnyNextLayers?

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Sep 2005 08:55:42 -0400

Francis,

I just spoke with Pasi (here in Athens) and I agree that "B" is wrong 
and thus confusing.  Here is my planned fixed text:

B. Even if a Next Layer Protocol has only one selector, e.g.,
            Mobility Header type, then the Local and Remote "port"
            selectors are used to indicate whether a system is
            willing to send and/or receive traffic with the specified
           "port" values. For example, if Mobility Headers of a
            specified type are allowed to be sent and received via an
            SA, then the relevant SPD entry would be set as follows:

            Local's
              next layer protocol = Mobility Header
              "port" selector     = Mobility Header message type

            Remote's
              next layer protocol = Mobility Header
              "port" selector     = Mobility Header message type

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 8 Sep 2005 15:57:28 +0300

> exactly this purpose, with an example and rationale.

As the IKEv2 simply specifies that the ICMP type and code are put to
the start and end port fields of the traffic selector payload, and it
also defines that if the OPAQUE needs to be expressed then it is
expressed as setting start port to 65535 and end port to 0, I do not
think there is any problem to express that kind of RFC2401bis
asymmetric SA within the IKEv2.

I.e. the TSi for the traceroute example will be

TS type = 4 (TS_IPV4_ADDR_RANGE)
IP Protocol ID = 1 (ICMPv4)
Start port = 7680 (0x1E00 = type 30 (traceroute), code = 0)
End port = 7935 (0x1EFF = type 30 (traceroute), code = 255)
Starting address = xxx (the network behind the sgw)
Ending address = yyy (the network behind the sgw)

And the TSr will be

TS type = 4 (TS_IPV4_ADDR_RANGE)
IP Protocol ID = 1 (ICMPv4)
Start port = 65535 (OPAQUE)
End port = 0 (OPAQUE)
Starting address = xxx (the network outside the sgw)
Ending address = yyy (the network outside the sgw)
-- 
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 17:19:08 +0200

Local's
   
               Remote's

=> fine!

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Sep 2005 01:24:06 +0200

I have another related question: is this valid:

           Local's
             next layer protocol = ICMP
             "port" selector     = <specific ICMP type1 & code1>

           Remote's
             next layer protocol = ICMP
             "port" selector     = <specific ICMP type2 & code2>

If yes, is the meaning that systems are willing to send and
receive traffic with type1/code1 for traffic from local to remote
and type2/code2 for traffic from remote to local?

I expect the answer is yes for both questions because IMHO this
reflects the intention of 4.4.1.3 for ICMP/MH "ports".

Thanks

PS: I believe a message in the list is enough, i.e., no clarification
in the 2401-bis document is necessary.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 12 Sep 2005 13:48:15 -0400

>in the 2401-bis document is necessary.

Yes, this would be a valid SPD entry with the intent you noted, i.e., 
different allowed ICMP message type.code combinations for the SAs in 
each direction.

Steve

---

From: Markku Savela <[email-masked]>
Date: Mon, 12 Sep 2005 22:48:35 +0300

> From: Stephen Kent <[email-masked]>

> different allowed ICMP message type.code combinations for the SAs in 

I fail to see how this trickery of putting ICMP/MH type/code into
remote and/or local port selectors SPD relates to controlling
whether such traffic is allowed only in, out or both ways?

Doesn't seem to be needed at all (at least I don't). If you want to
allow only inbound ICMP of specific type, you just write a selector
that specifies this type code and has destination address that matches
inbound. Same logic for outbound.

Seems to derive from some specific implementation. Specifying
asymmetric SPD for specific ICMP type is very simple in my
implementation, just writing a selector logically as

   "outbound proto=ICMP type=X"

I don't think 2401bis needs to tell how to impelemnt this internally.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Sep 2005 00:12:03 -0400

>I don't think 2401bis needs to tell how to impelemnt this internally.

2401bis defines the SPD and the format for SPD entries in support of 
translating them into IKE payloads in a consistent, well-understood 
fashion. it also explains the associated semantics, so that each peer 
has a reference as to what is meant by the data transferred by the 
IKE payloads. finally, the SPD spec is an externally visible, minimum 
management capability mandated by 2401(bis) to ensure that 
users/admins have a basic set of knobs for access control.

if your implementation provides external management controls 
equivalent to (or more capable than) what is specified in 2401bis, 
and if you explain how to map these visible controls to IKE payloads, 
then it is compliant.  we have examples of non-complaint 
implementations that, for example, do not allow the user/admin to 
order the SPD entries, a serious deficiency.

none of this is new, and it's way too late to comment on it.

Steve