headers
Russ Housley | 1 Sep 2005 18:29

IESG approved draft-hoffman-rfc3664bis-04 today

This document ( draft-hoffman-rfc3664bis-04.txt) was approved today.  It should appear in the RFC Editor queue soon.

Russ 
_______________________________________________
Ipsec mailing list
Ipsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 0 comments |
headers
Francis Dupont | 3 Sep 2005 01:36
Picon
Picon

ICMP and MH TSs for IKEv2

Even with the clarification draft the real world use of traffic selectors
with ICMP type/code or MH (Mobile IPv6 Header message) type is not
very clear:
 - IKEv2 (and IKEv1) establishes SAs by pairs, so if traffic from
   the initiator matches TSi -> TSr then is protected, the traffic
   from the responder which matches TSr -> TSi is protected too.
 - applied to ICMP does this mean that the selected type(s)/code(s) is/are
   protected in both way? (I think so according to the RFC 2401bis 4.4.1
   about SPD-S directionality)
 - the MH type is in the local "port" selector. What is the "local" TS,
   TSi only, or MH type and ICMP type/code are "aligned" (and how)?

Regards

Francis.Dupont <at> enst-bretagne.fr

PS: ipsec-tools seems to put the type in the source port and the code
in the destination port. The RFC 2401bis SPD syntax has 0, 1 or 2 upper
layer protocol items with at most one for ICMP, MH and ICMPv6.
Permalink | Reply | 2 comments |
headers
Markku Savela | 3 Sep 2005 11:19

Re: ICMP and MH TSs for IKEv2

> From: Francis Dupont <Francis.Dupont <at> enst-bretagne.fr>

> Even with the clarification draft the real world use of traffic selectors
> with ICMP type/code or MH (Mobile IPv6 Header message) type is not
> very clear:
>  - IKEv2 (and IKEv1) establishes SAs by pairs, so if traffic from
>    the initiator matches TSi -> TSr then is protected, the traffic
>    from the responder which matches TSr -> TSi is protected too.
>  - applied to ICMP does this mean that the selected type(s)/code(s) is/are
>    protected in both way? (I think so according to the RFC 2401bis 4.4.1
>    about SPD-S directionality)
>  - the MH type is in the local "port" selector. What is the "local" TS,
>    TSi only, or MH type and ICMP type/code are "aligned" (and how)?

I'm starting to lean on solution, where ICMP/MH type/code's in SA's TS
would always be in both local/remote port (or src/dst port). This way,
even multicast SA's would work without any special handling (an MC SA
that would be used for both receiving and sending).
Permalink | Reply | 1 comment |
headers
Francis Dupont | 3 Sep 2005 12:13
Picon
Picon

Re: ICMP and MH TSs for IKEv2

 In your previous mail you wrote:

   >  - the MH type is in the local "port" selector. What is the "local" TS,
   >    TSi only, or MH type and ICMP type/code are "aligned" (and how)?

   I'm starting to lean on solution, where ICMP/MH type/code's in SA's TS
   would always be in both local/remote port (or src/dst port). This way,
   even multicast SA's would work without any special handling (an MC SA
   that would be used for both receiving and sending).

=> I agree this solution seems good but it was only suggested and only
for ICMP in the clarifications I-D.

Thanks

Francis.Dupont <at> enst-bretagne.fr
Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 5 Sep 2005 19:01
Picon

RE: ICMP and MH TSs for IKEv2

Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    >  - the MH type is in the local "port" selector. What is 
>    >  the "local" TS, TSi only, or MH type and ICMP type/code 
>    >  are "aligned" (and how)?
>    
>    I'm starting to lean on solution, where ICMP/MH type/code's 
>    in SA's TS  would always be in both local/remote port (or 
<    src/dst port). This way, even multicast SA's would work 
>    without any special handling (an MC SA that would be used 
>    for both receiving and sending).
>    
> => I agree this solution seems good but it was only suggested and 
> only for ICMP in the clarifications I-D.

I agree, this solution seems to apply both to ICMP and MH. We'll 
add some text about this in the next version of the clarifications 
I-D (hopefully appearing before the Toronto IPsec/IKEv2 interop).

Best regards,
Pasi
Permalink | Reply | 1 comment |
headers
Stephen Kent | 6 Sep 2005 16:40
Picon

RE: ICMP and MH TSs for IKEv2

At 8:01 PM +0300 9/5/05, Pasi.Eronen <at> nokia.com wrote:
>Francis Dupont wrote:
>>   In your previous mail you wrote:
>>
>>     >  - the MH type is in the local "port" selector. What is
>>     >  the "local" TS, TSi only, or MH type and ICMP type/code
>>     >  are "aligned" (and how)?
>>   
>>     I'm starting to lean on solution, where ICMP/MH type/code's
>>     in SA's TS  would always be in both local/remote port (or
><    src/dst port). This way, even multicast SA's would work
>>     without any special handling (an MC SA that would be used
>>     for both receiving and sending).
>>   
>>  => I agree this solution seems good but it was only suggested and
>>  only for ICMP in the clarifications I-D.
>
>I agree, this solution seems to apply both to ICMP and MH. We'll
>add some text about this in the next version of the clarifications
>I-D (hopefully appearing before the Toronto IPsec/IKEv2 interop).
>
>Best regards,
>Pasi

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.

Steve
Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 7 Sep 2005 09:55
Picon

RE: ICMP and MH TSs for IKEv2

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
Permalink | Reply | 10 comments |
headers
Francis Dupont | 7 Sep 2005 18:06
Picon
Picon

Re: ICMP and MH TSs for IKEv2

 In your previous mail you wrote:

   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.

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

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

=> where is it in the 2401-bis?

   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.

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

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

=> IMHO this OneNextLayerProtocol specifies explicitely symmetrical case.

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

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

Francis.Dupont <at> enst-bretagne.fr

PS: BTW both IKEv2 and RFC 2401bis should be updated about this point.
Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 7 Sep 2005 18:34
Picon

RE: ICMP and MH TSs for IKEv2

Francis Dupont wrote:
> 
>  In your previous mail you wrote:
> 
>    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.
>    
> => in fact there is a real issue about what means symmetrical in
> this context...

Yes, there are probably several possible meanings.

I meant a situation where, say, ICMP type 8 from host A to B is
protected one way (say, ESP with AES), but ICMP type 8 in the 
other direction (B to A) is done some other way (say, no IPsec 
processing at all, or AH only).

>    (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.)
>    
> => where is it in the 2401-bis?

It's probably not explicitly mentioned, but it's easy to get that
situation if you configure your SPD/SAD manually.

>    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.
>    
> => I agree but if we can solve the asymmetrical case too...
> 
>    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).
> 
> => IMHO this OneNextLayerProtocol specifies explicitely 
> symmetrical case.

Depends on what exactly is meant by "symmetrical", I guess.

It's not symmetrical in the sense that it allows the situation I
described above (traffic in different directions get different
treatment).

>    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).
>    
> => 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!
<snip>
> PS: BTW both IKEv2 and RFC 2401bis should be updated about this point.

I don't see why 2401bis would need any updates. And I'm definitely
against adding any new functionality to IKEv2 at this stage.

Best regards,
Pasi
Permalink | Reply | 1 comment |
headers
Stephen Kent | 8 Sep 2005 08:27
Picon

RE: ICMP and MH TSs for IKEv2

At 10:55 AM +0300 9/7/05, Pasi.Eronen <at> nokia.com 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
Ipsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 8 comments |

Gmane