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

From: [email-masked]
Date: Wed, 7 Sep 2005 19:34:15 +0300

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

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

---

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

=> so call this situation the asymmetrical case for ICMP.
It is not (yet) possible with 2401bis/IKEv2 mainly by lack
of accurate wording.

   
=> I can't see how to configure the SPD-S to get this. IMHO
it seems the rfc2041bis SPD-S and IKEv2 have now equivalent
capabilities, i.e., on the contrary of RFC 2401 and IKEv1,
the rfc2401bis is not more "powerful" than IKEv2.

   
=> the opposite of the "asymetrical situation".

=> how? the OneNextLayerProtocol is not attached to one side.

   > where traffics are known to be always asymmetrical!

=> I should have added that (4) is the natural extension of (3),
i.e., if (4) is the rule a symmetrical config will give (3).

   > PS: BTW both IKEv2 and RFC 2401bis should be updated about this point.
   
   I don't see why 2401bis would need any updates.

=> how the asymmetrical situation is handled is not described in a sound
(or even clear enough) way.

   And I'm definitely against adding any new functionality to IKEv2 at
   this stage.
   
=> according to Stephen, this is not a new functionality, it is a
functionality we agreed about but which is not described in a clear enough/
sound way (and here only the "clear enough" applies to IKEv2).

Thanks

[email-masked]