Subject: Re: [secdir] SECDIR review of draft-ietf-softwire-encaps-ipsec-01

From: Lou Berger <[email-masked]>
Date: Wed, 28 Jan 2009 14:19:38 -0500

Julien,
         Much thanks for your review & comments.  Sorry about the 
delayed response.

At 11:00 AM 12/16/2008, Julien Laganier wrote:
>I have reviewed this document as part of the security directorate's
>ongoing effort to review all IETF documents being processed by the
>IESG. These comments were written primarily for the benefit of the
>security area directors. Document editors and WG chairs should treat
>these comments just like any other last call comments.
>
>I'm no BGP expert thus I'm simply copy/pasting the draft's Abstract
>below to give people some background:
>
>    The BGP Encapsulation Subsequence Address Family Identifiers (SAFI)
>    provides a method for the dynamic exchange of encapsulation
>    information, and the indication of encapsulation protocol types to be
>    used for different next hops.  Currently support for GRE and L2TPv3
>    tunnel types are defined.  This document defines support for IPsec
>    tunnel types.
>
>The document is short and thus I have few comments:
>
>In section 2. "IPsec Tunnel Encapsulation Types"
>------------------------------------------------
>
>"
>    Per [ENCAPS-SAFI], tunnel type is indicated in the Tunnel
>    Encapsulation attribute. This document defines the following tunnel
>    type values:
>
>      - AH in Tunnel-mode: Tunnel Type = 3 [RFC4302]
>
>      - ESP in Tunnel-mode: Tunnel Type = 4 [RFC4303]
>
>      - IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
>        [RFC4023]
>"
>
>I made the same comment for the softwire framework draft but I'm
>repeating it here for completeness: The use of IPsec transport mode to
>protect tunnels is diminished significantly compared to the protection
>afforded by IPsec tunnel mode and thus it would be good to point that
>out in the Security Considerations section of this document. For
>example RFC 4301 includes the following paragraph:
>
>"
>                                                     [...] The access
>    control functions that are an important part of IPsec are
>    significantly limited in this context, as they cannot be applied to
>    the end-to-end headers of the packets that traverse a transport mode
>    SA used in this fashion.  Thus, this way of using transport mode
>    should be evaluated carefully before being employed in a specific
>    context.
>"

Point taken, will add the following to the first paragraph of 
security considerations section:

     The security considerations from those documents as well as
     [RFC4301] apply to the data plane aspects of this document.
     Notably, this includes the comment on Page 14 of [RFC4301] in
     reference to the use of transport mode.

>In section 3 "Use of IPsec"
>---------------------------
>
>"
>    If a R1 is a BGP speaker that receives an Encapsulation SAFI update
>    from another BGP speaker, R2, then if R1 has any data packets for
>    which R2 is the BGP next hop, R1 MUST initiate an IPsec SA of the
>    specified "tunnel type", and all such data packets MUST be sent
>    through that SA.
>
>    Let R1 and R2 be two BGP speakers that may send data packets through
>    R3, such that the data packets from R1 and from R2 may be received by
>    R3 over the same interface.  Then if R3 has sent an update containing
>    an Encapsulation SAFI, and if this update specifies an IPsec tunnel
>    type, and if this update is received by R2, and an Encapsulation-SAFI
>    with an IPsec tunnel type, SHOULD also be received by R1. [..]
>"
>
>Maybe this is just me but I have read the last sentence above 5 or 6
>times and I have trouble to parse it. It seems to be some comas should
>disappear. Would this rewording be appropriate:
>
>"If R3 has sent an update containing an Encapsulation SAFI that
>specifies an IPsec tunnel type to R2, then an update containing an
>Encapsulation SAFI that specifies an IPsec tunnel SHOULD also be
>received by R1" ?

How about:
     In this case, when R3 sends an Encapsulation SAFI which indicates
     an IPsec tunnel type to R2, then R3 SHOULD also send an update
     specifying an Encapsulation SAFI with an IPsec tunnel type to R1.

>Nits:
>-----
>
>In couple of places you're using a reference to a document as a
>grammatical object while I understand a reference has a parenthetical
>nature and thus can't play that role.
>
>E.g. "This document does not specify the use of the sub-TLV types
>defined in [ENCAPS-SAFI] with these tunnel types."
>
>Should be reworded into something like "This document does not specify
>the use of the sub-TLV types defined in the BGP Information SAFI and
>BGP Tunnel Encapsulation Attribute specification [ENCAPS-SAFI] with
>these tunnel types."

This is pretty common in IETF documents...

>This is all for this document. Hope this is useful.

It is, thank you.

Lou

>--julien

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 Jan 2009 17:14:54 -0500

Lou,

As an IPsec guy with an interest in routing, I had a few questions 
about this document.

The current version of IPsec (See RFC 4301) suggests use of ESP-NULL 
for the latter security services, rather that AH. However, this 
document lists ESP and AH as the two IPsec encapsulation options. It 
might be preferable to cite ESP-NULL in lieu of AH here, especially 
if integrity is likely to be a commonly-selected service.  (It was 
not clear from the security consideration section whether the primary 
focus of this tunnel option was to provide confidentiality and 
integrity for traffic, or integrity.)

I also think that the IPsec architecture document (RFC 4301) ought to 
be cited here as normative, along with the IPsec protocol specs.  If 
an RFC defines a means of triggering use of IPsec, and defines 
parameters that indicate which  then the IPsec architecture document 
and the relevant IPsec protocol documents strike me as normative 
references. For example, when the encapsulation type calls for an AH 
or ESP tunnel, the two routers in question need to have SPD entries 
that specify the parameters for the tunnel that will be created, 
e.g., indicating algorithms, modes, and optional services like 
anti-replay. Just saying that a router will create an AH or ESP 
tunnel is not specific enough to say what really will happen. The SPD 
entries at each end will be used to fill in the details needed to 
allow successful creation of the tunnel.  So, it seems appropriate to 
note this in the document, and to cite the architecture spec as 
normative.

Finally, there is no cite for IKE.  White it is true that IPsec does 
not require use of IKE, I believe that the vast majority of IPsec 
implementation use IKE. So, why not call for IKE use here as well, to 
negotiate the SA parameters and manage keys. The IETF prefers 
automated key management for security protocols, and IKE is the 
designated key management protocol for IPsec. Since the document 
cites the newest versions of AH and ESP, both of which assume use of 
IKEv2, the right cite is to that version of IPsec.

Thanks,

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 29 Jan 2009 18:28:21 -0500 (Eastern Standard Time)

On Thu, 29 Jan 2009, Stephen Kent wrote:

> Lou,
>
> As an IPsec guy with an interest in routing, I had a few questions about this 
> document.
>
> The current version of IPsec (See RFC 4301) suggests use of ESP-NULL for the 
> latter security services, rather that AH. However, this document lists ESP 
> and AH as the two IPsec encapsulation options. It might be preferable to cite 
> ESP-NULL in lieu of AH here, especially if integrity is likely to be a 
> commonly-selected service.  (It was not clear from the security consideration 
> section whether the primary focus of this tunnel option was to provide 
> confidentiality and integrity for traffic, or integrity.)

I found it somewhat ironic that signalling the use of public key 
cryptography in these IPsec tunnels is itself to be protected by TCP MD5:

    When the IPsec Tunnel Authenticator sub-TLV is used, it is highly
    RECOMMENDED that the integrity of the BGP session itself be
    protected.  This is usually done by using the TCP MD5 option
    [RFC2385].

>
> I also think that the IPsec architecture document (RFC 4301) ought to be 
> cited here as normative, along with the IPsec protocol specs.  If an RFC 
> defines a means of triggering use of IPsec, and defines parameters that 
> indicate which  then the IPsec architecture document and the relevant IPsec
                 ^^
                 ??

> protocol documents strike me as normative references. For example, when the 
> encapsulation type calls for an AH or ESP tunnel, the two routers in question 
> need to have SPD entries that specify the parameters for the tunnel that will 
> be created, e.g., indicating algorithms, modes, and optional services like 
> anti-replay. Just saying that a router will create an AH or ESP tunnel is not 
> specific enough to say what really will happen. The SPD entries at each end 
> will be used to fill in the details needed to allow successful creation of 
> the tunnel.  So, it seems appropriate to note this in the document, and to 
> cite the architecture spec as normative.
>
> Finally, there is no cite for IKE.  White it is true that IPsec does not 
> require use of IKE, I believe that the vast majority of IPsec implementation 
> use IKE. So, why not call for IKE use here as well, to negotiate the SA 
> parameters and manage keys.

There's no cite, true.  But I see that a reference to using IKE (but not 
IKEv2) in section 3 (for negotiation of policy) and in section 4.1 (for 
obtaining a certificate for the router that sent a tunnel authenticator 
sub-TLV).

>                             The IETF prefers automated key management for 
> security protocols, and IKE is the designated key management protocol for 
> IPsec. Since the document cites the newest versions of AH and ESP, both of 
> which assume use of IKEv2, the right cite is to that version of IPsec.
>
> Thanks,
>

--Sandy

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 29 Jan 2009 18:30:53 -0500 (Eastern Standard Time)

Sorry, I was intended to point to the "which  then" part of the sentence. 
I don't know that the spacing was retained by my mailer.

--Sandy

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Jan 2009 12:43:04 +0200

> obtaining a certificate for the router that sent a tunnel authenticator 

The draft-ietf-softwire-mesh-framework draft says that negotiation
is done using IKEv2:

----------------------------------------------------------------------
6. Softwire Signaling
...
                ... A softwire based on IPsec would use
   standard IKEv2 (Internet Key Exchange) [RFC4306] and IPsec [RFC4301]
   signaling, as that is necessary in order to guarantee the softwire's
   security properties.
...
14.3. Cryptographic techniques
...
   Since the softwires are set up dynamically as a byproduct of passing
   routing information, key distribution MUST be done automatically by
   means of IKEv2 [RFC4306], operating in main mode with preshared keys.
   If a PKI (Public Key Infrastructure) is not available, the IPsec
   Tunnel Authenticator sub-TLV described in [ENCAPS-IPSEC] MUST be used
   and validated before setting up an SA.
...
----------------------------------------------------------------------

(altought as I said in my earlier mail the "main mode with preshared
keys" text should not be there, as that is using IKEv1 terms). 

So softwire do use IKEv2 ad new IPsec architecture, but I agree that
draft-ietf-softwire-encaps-ipsec should also have references to those
documents.
-- 
[email-masked]
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 Jan 2009 10:24:28 -0500

At 6:28 PM -0500 1/29/09, Sandra Murphy wrote:
>>The current version of IPsec (See RFC 4301) suggests use of 
>>ESP-NULL for the latter security services, rather that AH. However, 
>>this document lists ESP and AH as the two IPsec encapsulation 
>>options. It might be preferable to cite ESP-NULL in lieu of AH 
>>here, especially if integrity is likely to be a commonly-selected 
>>service.  (It was not clear from the security consideration section 
>>whether the primary focus of this tunnel option was to provide 

good point,  I missed that. That's what happens when one expands the 
set of options being negotiated to include security protocols.

>>
>>I also think that the IPsec architecture document (RFC 4301) ought 
>>to be cited here as normative, along with the IPsec protocol specs. 
>>If an RFC defines a means of triggering use of IPsec, and defines 
>>parameters that indicate which  then the IPsec architecture 
>>document and the relevant IPsec
>                 ^^
>                 ??

whoops. My editing deleted more that I intended.  I think the 
sentence shoud read:

If an RFC defines a means of triggering use of IPsec, and defines 
parameters that indicate which IPsec protocols are to be used, then 
the IPsec architecture document and the relevant IPsec

>>protocol documents strike me as normative references. For example, 
>>when the encapsulation type calls for an AH or ESP tunnel, the two 
>>routers in question need to have SPD entries that specify the 
>>parameters for the tunnel that will be created, e.g., indicating 
>>algorithms, modes, and optional services like anti-replay. Just 
>>saying that a router will create an AH or ESP tunnel is not 
>>specific enough to say what really will happen. The SPD entries at 
>>each end will be used to fill in the details needed to allow 
>>successful creation of the tunnel.  So, it seems appropriate to 
>>Finally, there is no cite for IKE.  White it is true that IPsec 
>>does not require use of IKE, I believe that the vast majority of 
>>IPsec implementation use IKE. So, why not call for IKE use here as 
>>well, to negotiate the SA parameters and manage keys.
>
>There's no cite, true.  But I see that a reference to using IKE (but 
>not IKEv2) in section 3 (for negotiation of policy) and in section 
>4.1 (for obtaining a certificate for the router that sent a tunnel 
>authenticator sub-TLV).

Whoops, again. I missed that too. But, if one calls for use of the 
latest AH and ESP specs, then IKEv2 is needed, since these versions 
of the IPsec protocols rely on IKEv2 negotiation capabilities.

Steve