Re: [CCAMP] [karp] draft-mahesh-karp-lmp-analysis overflow IPsec

[t.petch <[e-mail]>]

Picking up on 6), counter overflow, I was thinking that if the aim was
to detect a failure in 10ms, then the rate of keepalives is 300/sec for
which a 32-bit counter would wrap in several months.  Which does not
seem terribly insecure or not enough to make an incompatible change to
the PDUs so yes, justification needed - like detecting failures in
10microsecond.

The thought I had that is still maturing was that the Security
Considerations of RFC4204 look good but that they are IPsec-based and I
have not had much exposure to IPsec lately. Generally, I do not see much
discussion of IPsec and am unsure where the skills exist to evalute that
part of  this
RFC against karp (but perhaps not in either CCAMP or karp WGs).  I see
no parallel of UDP with IPsec as a starting point within the domain of
routing protocols (or much else - I seem to recall having seen Microsoft
using that combination).

Tom Petch

p.s. Still cross-posting pro tem, until directed otherwise.

----- Original Message -----
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, March 15, 2014 6:30 PM

Hi,

Tom's review of this document has tipped my guilt index. Here is my
brief review.

1. Although LMP is not strictly speaking a routing protocol, I have no
   objections to an analysis of the security considerations.  I do,
   however, wonder whether RFC 6518 provides the best basis for such an
   analysis considering how that RFC is tuned towards routing protocols
   which are a different animal from LMP. I note that LMP is not listed
   in RFC 6518 although it is in the KARP charter.

2. I don't really think this document does what it sets out to do. Or
   if it does, it does so in a very round-about way.

   RFC 6518 Section 4.2 provides a series of steps. I might have
   expected corresponding sections in this draft. A step-by-step
   approach would have made cross-checking against RFC 6518 very much
   easier.

3. I think there is a lot of text in this document that could be pruned.
   No need to repeat background material on security aims of the IAB.
   No need to quote extensively from other RFCs when a reference will
   do. It would be nice to cut this document down to the bare bones so
   that readers can see the bottom line.

4. Section 2.3 says:
   "LMP [RFC4204] recommends the use of IPSec for authentication"
   I think that RFC 4204 is stronger than a recommendation.

5. Section 2.3 says:
   "That document [RFC 4204] also states that there is currently no
   requirement that LMP headers or payload be encrypted."
   I think that Section 15.1 of RFC 4204 is stronger than "currently".

6. Section 2.4 says
    The 32-bit Message_Id number space is not large enough to guarantee
    that the Message_Id number will not wrap around within a reasonable
    long period.  Therefore, the system is susceptible to a replay
    attack.
   This is a very important statement. (I don't think it falls within
   the remit of RFC 6518, but it still deserves to be made and
   considered.)

   However, there is no analysis of why it is believed that 32 bits
   are not enough for a "reasonable long period". How often does the
   author believe that a new Message_Id will be used in normal LMP
   processing? What is a "reasonable long period"? What are the replay
   characteristics that would result?

7. Section 2.4 says
    In addition, LMP does not provide for a generation of a unique
    monotonically increasing sequence numbers across a failure or a
    restart.
   This is partially true. The LMP protocol spec does not require this.
   On the other hand, the protocol spec does require that a restart be
   detectable at the remote end. So why does the author believe
   monotonic increasing is needed over a restart? Compare a restart with
   a new CC.

8. Section 4 of this document claims to compare against sections 4.1
   and 4.2 of RFC 6518. The Abstract only promised to use section 4.2.
   However, I find it hard to see the comparison with 6518 in the text.

9. The "solutions" in Section 4.1 have me more than a little confused.
   - "Maintaining Message_Id numbers in stable memory" presumably means
     non-volatile or persistent storage. This can hardly be a protocol
     requirement, so let's dig...
     I think that this is intended to be implementation advice in order
     to meet the requirement that Message_Id is monotonic increasing
     even through restart. But I don't see that requirement in RFC 4204
     and I don't see it derived in this document. So, while an
     implementation could do this (and note that 4204 discusses what
     happens when an LMP implementation can and cannot retain
     information about a TE link over a restart) I don't see why an
     implementation would be required to do this.
     Maybe it is a suggestion that it is OK to give an implementer, but
     it seems heavy.
   - Two methods are suggested to seed the Message_Id field after
     restart. I have two issues with this:
     - Firstly it goes against the previous suggestion that Message_Id
       needs to be retained in non-volatile memory over a restart. If
       you are going to use a clock-based seed then why bother storing
       the information?
     - Secondly it assumes that an implementation needs this advice.
       Well, perhaps it does! But 4204 says nothing about how Message_Id
       is seeded and it would be a naïf implementer who keeps returning
       to one when a control channel restarts (or who started at one in
       the first place).
    - The final paragraph of 4.1 seems to be trying to say a lot in one
      paragraph. I see:
      - There is already a "handshake" defined (presumably you mean
        Section 8 of RFC 4204) and so the "rollback of Message_Id
        numbers across a system restart or failure" is not actually an
        issue that needs attention.
      - There is a problem with one of the two clock-based mechanisms
        you suggested in the previous bullet list. Perhaps it would be
        better to not make the suggestion?

10. Having made a big thing earlier in the document about Message_Id
    wrapping and the risk from replay attacks, Section 4.1 doesn't
    suggest any solution (not that I think one is needed).

11. Disappointingly, there is no discussion of key management in the gap
    analysis section. Does that mean that LMP scores top marks on the
    KARP scale and needs no further work?

All in all, I think the totality of the document boils down to Section
4.1, and I don't see it identifying any specific issues for LMP that
need the attention of a protocol team. Of course, this might change if
the document gives attention to key management, but I don't think so.

Thus, while it is reassuring to have a note of record saying "LMP
security seems OK", I don't think we need to make a big thing of it.

Thanks,
Adrian