Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt

From: Alex Zinin <[email-masked]>
Date: Fri, 2 Apr 2004 19:03:02 -0800

Steve-

Thanks for looking at this. My comments inline below.

I've added the IDR mailing list, since your comments cover the base spec as
well.

Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:
> Steve,

> The text explaining why the MD5 checksum is not a good candidate for 
> use in broader IETF protocol contexts is very well written.

> The discussion of why BGP-4 can't easily change at this time to 
> another integrity mechanism is also very good. However, when I looked 
> quickly at the new BGP draft (intended to replace the extant RFC) I 
> was unable to find any discussion of using the MD5 option. There are 
> references to RFC 2385 in the discussion of what has changed, and in 
> the security considerations section, and the normative references 
> section. But a search on "MD5," "RFC 2385," "authentication," 
> "integrity," or "security" does not point a reader to any text that
> says in any detail how to use this TCP option in the BGP context.

As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP
Sessions via the TCP MD5 Signature Option", in turn, describes how the option
can be used to secure a TCP sessions, for BGP in particular. Is there something
specific you were looking for?

> The
> section entitled "TCP Options that may be used with BGP" makes no 
> reference to it. Can someone point me to where the new BGP document 
> actually says how this TCP option is used?

Appendix E "TCP options that may be used with BGP" could indeed mention that the
MD5 option can be used for BGP sessions. Yakov, please log this.

> Also, I note that the document abstract says:

> "Routing information exchanged via BGP supports only the destination-
>     based forwarding paradigm, which assumes that a router forwards a
>     packet based solely on the destination address carried in the IP
>     header of the packet. This, in turn, reflects the set of policy
>     decisions that can (and can not) be enforced using BGP. BGP can
>     support only the policies conforming to the destination-based
>     forwarding paradigm."

> The term "solely" seems inappropriate, since it ignores the role that 
> local policy plays in route selection, right? I think I know what the 
> authors meant to say, but the text does not seem to be correct in 
> this regard.

It seems that the abstract is correct, actually. Routers indeed _forward_
packets using solely the destination address from the packet, as opposed to
using say destination and source address, or even more granular forwarding
decisions. Policies are taken into consideration when the RIB and FIB are
constructed, which is not part of forwarding.

> LDP is a much newer protocol and so there is less of a "large 
> installed base that has been using this for years" sense.

We do have quite considerable installed base for LDP and strictly speaking it
has been there for a few years. So, though the statement may not sound as strong
when applied to LDP, it is correct.

>  I am also 
> disturbed that the LDP spec (RFC 3036) refers to this as a signature 
> as well, and incorporates bad text from the old BGP RFC, e.g., "... 
> acts like a signature for that segment .." further perpetuating the 
> confusion between message authentication codes and digital 
> signatures. Any chance we can get this fixed in both the BGP document 
> before it progresses and in the next rev of 3036?

The BGP spec (neither old nor new) does not include this terminology, so I don't
think we need to fix it from this perspective.

Improvement of the LDP spec could be considered by the MPLS WG when it starts
working on a new revision of the spec.

Thank you.

Alex

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Alex Zinin <[email-masked]>
Date: Fri, 2 Apr 2004 19:03:02 -0800

Steve-

Thank you.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Tue, 6 Apr 2004 16:26:38 -0700

Steve-

> the BGP document cites mandatory use of RFC 2385 as one of the 
> changes, up front, but then never makes any reference to the RFC in 
> the text. That's not a good way to communicate the intent of the 
> change, i.e., the intent of the change has not been integrated into 
> the body of the spec.

It seems that you simply have missed the following reference in the "Security
Considerations" section:

 draft-ietf-idr-bgp4-23.txt:

    The authentication mechanism that an implementation of BGP MUST sup-
    port is specified in [RFC2385]. The authentication provided by this
    mechanism could be done on a per peer basis.

    BGP vulnerabilities analysis is discussed in [BGP_VULN].

> in the context of Steve Bellovin's document there is no reason to
> perpetuate the error of the RFC 2385 title, i.e., to continue to 
> refer to the message authentication code created by the use of a 
> shared secret and a hash function as a "signature."  One might even 
> take this opportunity to point out that the title of the RFC is 
> misleading and should not be confused with digital signature 
> technologies.

My understanding is that Steve used the wording from the 2385's title on
purpose, since we're talking about a specific document with a specific title,
plus about a TCP option with a specific name (though now considered misleading).

> then the text should say that LDP represents as big an installed base 
> as BGP's use of MD5, if that is the case. If not, then find some 
> accurate but similarly persuasive characterization that justifies 
> this use.

OK. We'll see if the wording can be improved.

> For contrast, RFC xxxx specifies use of MD5 in the same 
> fashion for OSPF security, but nobody is suggesting that this be 
> approved, presumably because there is no large, installed base, right?

RFC 2328 includes the OSPF MD5 authentication option (similar to TCP-MD5 in its
transport nature). It's widely deployed and is a full IETF Standard. If you mean
"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of
only one or two implementations.

> you are right that the primary focus of this discussion is 
> progression of BGP. But, since you argued that LDP is appropriately 
> included in the rationale discussion for this document, I assume you 
> will want to progress that RFC too,
> otherwise why bother mentioning it now?  I would rather not have to 
> revisit this at that time, so I suggest you ask the MPLS WG to make a 
> note of this error now.

Looking at the LDP spec, it uses the word "signature" as part of the reference
to the "TCP MD5 Signature Option", specified in 2385. While it could be argued
that 2385 uses incorrect terminology, it would be confusing to refer to it as
something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication
Option", as this is not what 2385 specifies.

Thanks

Alex

---

From: Alex Zinin <[email-masked]>
Date: Tue, 6 Apr 2004 16:26:38 -0700

Steve-

Thanks

Alex

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 2004 09:49:49 -0400

>constructed, which is not part of forwarding.

Good point.

this use. For contrast, RFC xxxx specifies use of MD5 in the same 

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 2004 09:49:49 -0400

Good point.

Steve

---

From: Alex Zinin <[email-masked]>
Date: Thu, 8 Apr 2004 16:52:04 -0700

This is a forwarded message
From: Stephen Kent <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Steve Bellovin <[email-masked]>, [email-masked]
Date: Wednesday, April 7, 2004, 8:09:53 AM
Subject: [saag] draft-iesg-tcpmd5app-00.txt

===8<==============Original message text===============
>     BGP vulnerabilities analysis is discussed in [BGP_VULN].

No, I didn't miss it, Alex. I consider it a trivial reference that 
fails to do an adequate job. The Security Considerations section of a 
document is not where one first specifies a requirement for a 
protocol. It is a place to comment upon what has already been 
specified, putting it in context relative to security.

>plus about a TCP option with a specific name (though now considered 

Alex, the terminology was always wrong, and I pointed that out to the 
IESG when the RFC was out for last call years ago. But Jeff Schiller 
apparently didn't think the terminology error was worth fixing, and I 
doubt that the rest of the IESG was concerned back then. Don't phrase 
this as though we're in the realm of revisionist political 
correctness. It was wrong then, and it's still wrong.

>	<SNIP>

Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, 
I was referring to 2238. We have a slightly odd situation here. 
Steve's document explains why BGP is being progressed even though it 
contains a normative reference to an RFC (TCP MD5 ...) that will not 
be progressed. The argument is that the latter RFC is technically 
poor, but it's not so awful to use it with BGP considering the 
context, because it is widely deployed, and because it is the only 
point-to-point authentication mechanism defined for BGP.  Then there 
is the minor mention of LDP at te end.

You suggest, above, that OSPF's use of MD5 is also widely deployed, 
something of which I was not aware. (Or did you just mean that many 
OSPF implementations support the feature, but you don't know if it is 
tuend on?) OSPF does not use the TCP MD5 option, but rather uses MD5 
in the same marginal way internally. So, in one sense there is no 
need to mention this in Steve's document, because it is just 
explaining why the IESG is making an exception for BGP, and LDP in 
the future. But, in a more fundamental sense, we have already 
endorsed the inappropriate use of MD5 in routing protocols in terms 
of OSPF, and we're merely continuing the tradition with BGP and LDP 
:-).

	<SNIP>

>Option", as this is not what 2385 specifies.

If you look at Steve's document, he uses the right terminology 
throughout, while referring to the document via its RFC number. 
That's a good model for any document that wants to avoid perpetuating 
the terminology error inherent in the title of 2385.

Steve

===8<===========End of original message text===========

---

From: Alex Zinin <[email-masked]>
Date: Thu, 8 Apr 2004 16:52:04 -0700

<SNIP>

Steve

---

From: Alex Zinin <[email-masked]>
Date: Thu, 8 Apr 2004 16:52:18 -0700

This is a forwarded message
From: Steven M. Bellovin <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: Alex Zinin <[email-masked]>, [email-masked]
Date: Wednesday, April 7, 2004, 8:13:10 AM
Subject: [saag] draft-iesg-tcpmd5app-00.txt

>the terminology error inherent in the title of 2385.

It's probably worth putting a note in my document noting the erroneous 
terminology in the title of 2385.  It's not a bad idea having a similar 
parenthetical note in the bgp document.

		--Steve Bellovin, http://www.research.att.com/~smb

---

From: Alex Zinin <[email-masked]>
Date: Thu, 8 Apr 2004 17:15:56 -0700

Steve-

 [putting IDR back on the Cc: list--I'd like the WG to be in the loop]

> specified, putting it in context relative to security.

Steve, would you mind making a suggestion on how the text could be improved?
E.g., would a separate section in the main body of the document specifying
the requirement for TCP-MD5 support be useful?

> correctness. It was wrong then, and it's still wrong.

I didn't mean to argue whether the terminology is right or wrong, I'll leave up
to you guys. My point was that we have to use the actual title of the document
when referring to it, even though the title may not accurately describe what's
inside. Anyway, Steve suggested that a clarifying note is put in the docs...

> tuend on?)

All more-or-less mature OSPF implementations I know of certainly support the
feature. As for deployment, OSPF MD5 _is_ being used in both SP and enterprise
networks. I do not have numbers for you, but even as of 3-4 years ago (when I
worked close with operators on a regular basis), it was not uncommon to see it
configured.

> OSPF does not use the TCP MD5 option, but rather uses MD5 
> the future.

Agreed.

> But, in a more fundamental sense, we have already 

It seems a discussion on why MD5 is inappropriate or insufficient in
routing protocols would be interesting if we take it to RPSEC.

Thanks.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Thu, 8 Apr 2004 17:15:56 -0700

Steve-

Agreed.

Thanks.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Thu, 8 Apr 2004 16:52:18 -0700

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Apr 2004 11:40:58 -0400

Alex,

>the requirement for TCP-MD5 support be useful?

A reasonable approach would be to have a section of the document that 
describes the use of this TCP option. It should explain why/when one 
would use the option in the context of BGP links and what protection 
it offers. Somewhere there should be a discussion of precautions 
should be taken re selection and use of keys, but maybe this is more 
of a BCP matter than a protocol standards matter.

>inside. Anyway, Steve suggested that a clarifying note is put in the docs...

actually, one often refers to an RFC by number in the text, and 
includes the title only in the references section.

>routing protocols would be interesting if we take it to RPSEC.

of course the issue is not MD5 per se, but the use of MD5 plus a 
secret bit string as a message authentication code, instead of HMAC, 
in any context.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Apr 2004 11:40:58 -0400

Alex,

Steve

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 14 Apr 2004 13:20:03 -0700

Alex,

> Appendix E "TCP options that may be used with BGP" could indeed mention that 
> the MD5 option can be used for BGP sessions. Yakov, please log this.

Sure.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 14 Apr 2004 13:38:17 -0700

Steve,

> it offers. 

Would you please produce the appropriate text for this section.

Thanks in advance.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 14 Apr 2004 14:03:50 -0700

Steve,

> parenthetical note in the bgp document.

Could you send me the note, so that I'll include it in the bgp doc.

Thanks in advance.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 14 Apr 2004 13:20:03 -0700

Alex,

Sure.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 14 Apr 2004 13:38:17 -0700

Steve,

Thanks in advance.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 14 Apr 2004 14:03:50 -0700

Steve,

Thanks in advance.

Yakov.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 16 Apr 2004 18:50:54 -0400

>Would you please produce the appropriate text for this section.

I'll try to provide some text when I return from vacation, in early May.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 16 Apr 2004 18:50:54 -0400

Steve

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 20 Apr 2004 06:54:37 -0700

Steve,

> I'll try to provide some text when I return from vacation, in early May.

Thanks !!! Looking forward to get the text.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 20 Apr 2004 06:54:37 -0700

Steve,

Yakov.