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

["Adrian Farrel" <[e-mail]>]

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

> -----Original Message-----
> From: CCAMP [mailto:[e-mail]] On Behalf Of t.petch
> Sent: 15 March 2014 12:37
> To: [e-mail]
> Cc: [e-mail]
> Subject: [CCAMP] draft-mahesh-karp-lmp-analysis
> 
> At IETF89, I recall CCAMP was asked if it would review the KARP analysis
> of LMP and four assented, of which I was one.  I would like any
> discussion to take place on an ietf.org list for its archiving and
> reliable distribution.  I would be interested to hear the views of the
> other three.
> 
> My first two thoughts are
> 
> - Section 1 seems misdirected.  KARP categorises routing protocols and
> one such is TCP point-to-point which encompasses BGP, LDP, PCEP and MSDP
> but notes in RFC6518, RFC6862 that LDP has an unsecured UDP part which
> then seems to be neglected.  LMP does not seem to fit any category being
> point-to-point over UDP with mandatory security and indeed seems to be
> ignored by KARP.  So I think that this section needs reworking.
> - Section 2.5 is a paraphrase of parts of s.7 of RFC4204 which seems to
> me less clear and less precise - I think that the original text should
> be used.
> 
> Tom Petch
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp