5 Apr 2004 15:49
Stephen Kent <kent <at> bbn.com>
2004-04-05 13:49:49 GMT
2004-04-05 13:49:49 GMT
At 7:03 PM -0800 4/2/04, Alex Zinin wrote:
Thanks for looking at this. My comments inline below.
I've added the IDR mailing list, since your comments cover the base spec as
Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:
> 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 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.
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.
> 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.
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. 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?
> 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.
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.
_______________________________________________ saag mailing list saag <at> mit.edu https://jis.mit.edu/mailman/listinfo/saag