Subject: old comments to Curtis's recommended addition to vulnerabilities draft

From: Sandy Murphy <[email-masked]>
Date: Wed, 25 Jun 2003 12:06:34 -0400 (EDT)

My response  to Curtis's message of Apr 3 don't appear on the idr mail
archive, so I am sending them now.

Fortunately, others made the same observations, although much more tersely
than what follows.

--Sandy

 Curtis, here are some comments on your recommended additions to the
 BGP Security Vulnerabilities Analysis draft.

 First, let me say that I agree with the "mandate TCP-MD5" part of the
 following:
   "Until such time as IPSEC is modified, there is little choice but to
    mandate TCP-MD5 implementation and recommend TCP-MD5 usage for BGP and
    discourage IPSEC usage for BGP."

 The fact that this version of BGP is supposed to document existing
 practice and the widespread deployment of TCP MD5 means that TCP MD5 is
 the only thing to mention in the current spec.

 But the "discourage IPSEC usage part" I don't agree with.

 You've brought up two points that I'd like to address:

 (1) IPSEC and filtering

   "These practical considerations yield the situation in which TCP-MD5,
   though cryptographic weak, far better serves ISP security needs than
   the cryptographicly much stronger IPSEC which makes packet filtering
   infeasible."

 This paragraph and other of your messages imply that using IPSEC
 obscures the port numbers.

 That's not the case when you are not doing confidentiality protection(^*).

 In IPSEC AH, the packet format leaves the port numbers in the clear.
 (I took the following format pictures directly from RFC 2402.)

                   BEFORE APPLYING AH
             ----------------------------
       IPv4  |orig IP hdr  |     |      |
             |(any options)| TCP | Data |
             ----------------------------

 In transport mode:

                   AFTER APPLYING AH
             ---------------------------------
       IPv4  |orig IP hdr  |    |     |      |
             |(any options)| AH | TCP | Data |
             ---------------------------------
             |<------- authenticated ------->|
                  except for mutable fields

 In tunnel mode:

           ------------------------------------------------
     IPv4  | new IP hdr* |    | orig IP hdr*  |    |      |
           |(any options)| AH | (any options) |TCP | Data |
           ------------------------------------------------
           |<- authenticated except for mutable fields -->|
           |           in the new IP hdr                  |

 The authentication data (keyed MAC, digital signature, etc.) is in the AH
 portion of the packet.

 Using IPSEC ESP with the null algorithm (i.e., authentication only) also
 leaves the port numbers in the clear.  Yes, I know it says "encrypted",
 but the null algorithm does nothing to the data.  (These pictures are
 from RFC2406)

                  BEFORE APPLYING ESP
             ----------------------------
       IPv4  |orig IP hdr  |     |      |
             |(any options)| TCP | Data |
             ----------------------------

 In transport mode:

                  AFTER APPLYING ESP
             -------------------------------------------------
       IPv4  |orig IP hdr  | ESP |     |      |   ESP   | ESP|
             |(any options)| Hdr | TCP | Data | Trailer |Auth|
             -------------------------------------------------
                                 |<----- encrypted ---->|
                           |<------ authenticated ----->|

 In tunnel mode:

             -----------------------------------------------------------
       IPv4  | new IP hdr* |     | orig IP hdr*  |   |    | ESP   | ESP|
             |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
             -----------------------------------------------------------
                                 |<--------- encrypted ---------->|
                           |<----------- authenticated ---------->|

 So the port numbers are visible in both cases.

 Maybe you meant that the filtering has to look down further into the
 packet to find the port numbers because they're offset from the usual
 position?  Are current hardware filtering mechanisms that rigid?

 Or perhaps the concern is that the authentication header is variable
 in size because the algorithms vary in how much authentication data
 they produce?  But the size of the AH header does not vary within one
 SPI - for any one SPI, the size of the AH is constant.  Can the filters
 not be configured individually for each peer?  Actually, if you were using
 the same algorithm for every peer, you wouldn't even have to adjust the
 filters - the AH header would be the same size for each peer.

 (^*) There have been discussion in the rpsec group of the need to
 protect the confidentiality of the routing data.  That doesn't
 necessarily mean using IPSEC ESP for confidentiality protection (it
 could mean doing the confidentiality protection within the protocol).
 Right now, the discussion is focussed on whether routing confidentiality
 is needed, with vehement speakers on both sides.  But it couldn't
 hurt to add your opinion about the layer at which that confidentiality
 should be provided.

 (2) IPSEC performance vs TCP MD5 performance

   "The
   capability of a single workstation with high speed interface to
   generate false traffic far exceeds the capability of software based
   decryption or appropriately priced cryptographic hardware.  From a
   practical standpoint, these networks are also better served by
   appropriate administrative care, filtering, and TCP-MD5 than by IPSEC."

 There's a suggestion here and in other of your messages that you
 believe that IPSEC processing is computationally much more expensive
 than TCP MD5 processing.

 I presume that you are concerned about the performance of the
 cryptographic parts of the two techniques, not the packet marshalling
 parts.  So let's compare the HMAC-MD5 processing supported in IPSEC AH
 with TCP MD5 processing.

 The TCP MD5 computation is:
    MD5 (packet contents, key)
    where packet contents = pseudo header, TCP header, TCP segment payload

 The HMAC-MD5 computation is:
    MD5 (key OR string, MD5 ( to-be-authenticated-text, key OR string)
    where "to-be-authenticated text" varies with IPSEC option used, as noted
    above

 Perhaps you are concerned about the fact that this looks like twice as
 many MD5 operations.  But that's not a true picture.  MD5 has to break
 up the to-be-authenticated input into 512 bit (bit, not byte) blocks and
 process the blocks separately.  So if your input is less than 512 bits
 (actually, it would have to be less than 448 bits, because of padding
 to position the key), then there's only one block to process.

 The output of MD5 is 16 bytes, so the HMAC outer MD5 always processes
 exactly one block of input.  So if your original to-be-hashed text is
 less than 448 bits, then the HMAC-MD5 runs the MD5 computation over
 two blocks.  Of course, if your payload is bigger than 448 bits (56
 bytes), the HMAC-MD5 runs the MD5 computation over at least 1 +
 (packetsizeinbits/512) blocks {the "at least" is because of that
 padding}.

 Since the payload being processed includes the TCP header
 and the ESP header (24 bytes and 10 bytes minimum, respectively) and
 the minimum BGP packet is a Keepalive at 19 bytes, it is pretty
 certain that most BGP packets, particularly BGP Update packets, will be
 larger than 56 bytes.

 So if the BGP packets were under 448 bits (56 bytes), HMAC would be
 twice as expensive as TCP MD5.

 If, however, the typical BGP packet were, say, 1024 bytes, then TCP MD5
 would process 1024/64 = 16 blocks and HMAC would process 17, so HMAC
 would be 6% more expensive.

 So IPSEC processing with HMAC might not be that much more expensive
 than TCP MD5, depending on the typical size of your BGP updates.

 (unless you're worried about the performance hit of doing the OR  :-))