[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2401bis Issue #67 -- IPsec management traffic



 In your previous mail you wrote:

   --============_-1148198426==_ma============
   Content-Type: text/plain; charset="us-ascii" ; format="flowed"
   
   At 16:32 +0200 9/18/03, Francis Dupont wrote:
   >  In your previous mail you wrote:
   >
   >    NO. what we said was that IKE SAs are treated specially by the
   >    host/SG that terminates or originates IKE traffic, and thus need not
   >    be subject to SPD/SAD controls.
   >   
   >=> IMHO it is convenient to be able to do both, i.e., the standard way
   >is that the IKE daemon asks itself for the "bypass" for UDP/500 but
   >the administrator can choose to enter specific SPD entries for UDP/500.
   >(for instance in order to solve the issue of IKE messages going throught
   >the local node)
   >BTW the RFC 2401 text is fine: it suggests this usage of the "bypass" but
   >mandates nothing more than common sense.

=> my purpose is to not rely on the "In host systems, applications MAY
be allowed to select what security processing is to be applied to the
traffic they generate and consume." to solve the "protection bootstrap"
problem of IKE. And the clean way is to offer a second way by the SPD.

   I looked at 2401 and the text I found in Section 4.4.1, is what I 
   assume folks had in mind when they thought that IKE traffic needed to 
   have SPD entries:
   
   "The SPD is used to control the flow of ALL traffic through an IPsec
   system, including security and key management traffic (e.g., ISAKMP)
   from/to entities behind a security gateway.  This means that ISAKMP
   traffic must be explicitly accounted for in the SPD, else it will be
   discarded.  Note that a security gateway could prohibit traversal of
   encrypted packets in various ways, e.g., having a DISCARD entry in
   the SPD for ESP packets or providing proxy key exchange.  In the
   latter case, the traffic would be internally routed to the key
   management module in the security gateway."
   
   What I think I had in mind here was that IKE (or other security 
   management) traffic passing  the through device needs to be accounted 
   for in the SPD. But, IKE traffic created in the device does not pass 
   through it, in my mind, and thus was exempt from this requirement.
   
=> in the PANA IPsec document you can get a nice case where the traditional
"bypass set by the IKE application" is not enough: a client (the PaC) has
a local ESP tunnel with a SG (the EP) and a second ESP tunnel with a
remote SG. The IKE messages with the remote SG should be encapsulated
locally (i.e., between the PaC and the EP). This can be done only with
a suitable SPD, for instance if the SPD has the "apply first match" style,
on the PaC the SPD in the out direction is:
 - source=PaC, destination=EP, ULP=UDP port 500: bypass
 - source=PaC, destination=remote SG, ULP=UDP port 500: ESP tunnel (PaC-EP)
 - source=PaC, destination=behind remote SG, ULP=any:
    ESP tunnel (Pac-remote SG) then ESP tunnel (PaC-EP)
 - source=PaC, destination=any, ULP=any: ESP tunnel (PaC-EP)

   Is there some place in 2401 that refers to bypass of UDP/500
   traffic for IKE?
   
=> no, IMHO we don't need such thing.

Thanks

Francis.Dupont@enst-bretagne.fr