Subject: [CCAMP] very very very rough CCAMP minutes

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 7 Mar 2014 13:31:02 +0000

...at the following link...

http://tools.ietf.org/wg/ccamp/minutes

feel free to amend/correct/suggest. Less rough version will be available soon.

BR
Daniele (& chairs)

---

From: t.petch <[email-masked]>
Date: Fri, 7 Mar 2014 18:36:48 +0000

----- Original Message -----
From: "Daniele Ceccarelli" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 07, 2014 1:31 PM
Subject: [CCAMP] very very very rough CCAMP minutes

<tp>
Um  I am getting
"
There are no ccamp minutes from IETF-89 yet, but an interactive document
which supports collaborative editing is provided below, for note-taking
during the meeting. This will be replaced by the meeting minutes when
they have been submitted.

You can open the document without embedding if you prefer that over the
embedded version below.
"
from that URI

Tom Petch

feel free to amend/correct/suggest. Less rough version will be available
soon.

BR
Daniele (& chairs)

------------------------------------------------------------------------
--------

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 10 Mar 2014 13:57:18 +0000

Hi Tom,

The minutes are not available yet, what is available is the raw notes taken during discussion on Etherpad, minutes will be available in the upcoming days and double-checked with the audio recordings.

I don't understand if you managed to see it or not. During the CCAMP sessions I couldn't open Etherpad via Chrome but succeded with IE...maybe some troubles with cookies...

BR
Daniele

> -----Original Message-----
> From: t.petch [mailto:[email-masked]]
> Sent: venerdì 7 marzo 2014 19:37
> To: Daniele Ceccarelli; [email-masked]
> Subject: Re: [CCAMP] very very very rough CCAMP minutes
> 
> during the meeting. This will be replaced by the meeting minutes when they
> have been submitted.
>

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Thu, 13 Mar 2014 11:04:07 +0000

Thanks, Daniele. I've added a couple of things based on my notes/recollections.

Cheers

Matt

From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, March 07, 2014 8:31 AM
To: CCAMP ([email-masked])
Subject: [CCAMP] very very very rough CCAMP minutes

BR
Daniele (& chairs)

---

From: t.petch <[email-masked]>
Date: Sat, 15 Mar 2014 12:36:32 +0000

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 15 Mar 2014 18:30:56 -0000

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

> From: CCAMP [mailto:[email-masked]] On Behalf Of t.petch
> Sent: 15 March 2014 12:37
> To: [email-masked]
> Cc: [email-masked]
> Subject: [CCAMP] draft-mahesh-karp-lmp-analysis
>

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 17 Mar 2014 08:36:09 +0000

Hi all,

some quick comments from me:

Firstly, as we know that all LMP messages are run over UDP with an LMP port number (except, in some cases, the Test messages, which may be limited by the transport mechanism for in-band messaging), so what are the special security requirements needed for LMP compared to the general UDP security? Note that I don't see the answer from Section 3.

Secondly, is there any security requirement for in-band messaging? 

Thirdly, for "Gap Analysis" in Section 4, it seems that Message_ID issue is the only "gap", is there any other "gap"?

Best Regards

Fatai

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of t.petch
Sent: Saturday, March 15, 2014 8:37 PM
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] draft-mahesh-karp-lmp-analysis

Tom Petch

---

From: t.petch <[email-masked]>
Date: Mon, 17 Mar 2014 10:34:05 +0000

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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, March 15, 2014 6:30 PM

Hi,

4. Section 2.3 says:

5. Section 2.3 says:

6. Section 2.4 says

7. Section 2.4 says

Thanks,
Adrian