Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt -- other comments

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 Jul 2006 23:56:23 -0400

A few more comments inline.

Curtis

    Christian & Tauber       Expires October 3, 2006                [Page 2]

    1.  Introduction

    1.1.  System Description

       BGP is described in RFC1771 [4], and, more recently, in an updated
       specification, RFC4271 [1], as a path-vector routing protocol.  BGP

RFC4271 obsoletes RFC1771.  It does not update RFC1771.  There is no
reason to mention RFC1771.

    Christian & Tauber       Expires October 3, 2006                [Page 3]

       Because ASes are autonomous in their operation, it is not possible to
       mandate secure operation by all ASes, nor would it be advisable to
       assume such operation.  Thus the primary goal of BGP security
       measures is to provide data to AS operators to enable BGP speakers to
       reject advertisements (UPDATE messages) that are not valid.  For
       example, UPDATE messages that represent erroneous binding of prefixes
       to an origin AS, or that advertise invalid paths (as defined later in
       this document) should be rejected.  Because BGP peering sessions take
       place in the context of TCP, the authentication and integrity
       guarantees usually association with TCP need to be provided in the
       face of possible active wiretapping attacks.  Using the terminology
       established in RFC 3552 [3], these peering sessions should be
       afforded data origin and peer entity authentication and connection-
       oriented integrity.

First sentence is fine.  Second sentence is also mostly OK.  Another
goal would be to allow a BGP speaker to prefer a given route over
another based on some measure of trust which is missed above.

The rest is about securing TCP and could be said in simpler terms.

       Security for subscriber traffic is outside the scope of this
       document, and of BGP security in general.  IETF standards for
       subscriber data security, e.g., IPsec, TLS, and S/MIME should be
       employed for such purposes.  While adoption of BGP security measures
       may preclude certain classes of attacks on subscriber traffic, these
       measures are not a substitute for use of subscriber-based security
       mechanisms of the sort noted above.

There is no such thing as "subscriber" traffic in BGP or anything IP.
It really shows that a MSO author had a hand in writing this.  Please
just drop this paragraph.  It is obvious to the intended audience that
we are not securing IP services.

    Christian & Tauber       Expires October 3, 2006                [Page 7]

    3.2.  Incremental deployment

       It will not be feasible to deploy a newly secured BGP protocol
       throughout the public Internet instantaneously.  It also may not be
       possible to deploy a such a protocol to all routers in a large AS at
       one time.  Because of this, there are several requirements that any
       proposed mechanism to secure BGP must consider.

       o  A BGP security mechanism MUST enable each BGP speaker to configure
          use of the security mechanism on a per-peer basis.

It may be a requirement to enable a security mechanism on routes which
are originated with the security mechanism.  For
example. customer-AS-1 and customer-AS-2 might want some form of
authentication.  Other AS don't.  These customer might transit
providers with ASx, ASy, ASz.  Within ASx, ASy, and ASz further path
authentication might be needed but only for origin-AS that are using
authentication.  This has no relevance to enabling something at the
ASx-ASy peering and the ASy-ASz peering.

       o  A BGP security mechanism MUST provide backward compatibility in
          the message formatting, transmission, and processing of routing
          information carried through a mixed security environment.  Message
          formatting in a fully secured environment MAY be handled in a non-
          backward compatible fashion though care must be taken to ensure
          UPDATES can traverse intermediate routers which don't support the
          new format.

       o  In an environment where both secured and non-secured systems are
          interoperating a mechanism MUST exist for secured systems to
          identify whether an originator intended the information to be
          secured.

These two paragraphs are the topic of the current discussion on the
list.

At some point we have to go back here when the discussion settles down.

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

---

From: Tony Tauber <[email-masked]>
Date: Fri, 21 Jul 2006 12:25:27 -0700 (PDT)

On Thu, 20 Jul 2006, Curtis Villamizar wrote:

>       While adoption of BGP security measures may preclude certain
>       classes of attacks on subscriber traffic, these measures are
>       not a substitute for use of subscriber-based security
> There is no such thing as "subscriber" traffic in BGP or anything
> IP.  It really shows that a MSO author had a hand in writing this.

No, it doesn't. 
It shows you spent a little time trying to guess people's biases. 
(Good deconsructionist methodology which I support.)

At the time I took over _editing_ the document, I'd been at Comcast
only a month or so. 
I guess my roots at NEARnet/BBN(Planet)/GTE/Genuity/Level3 weren't 
sufficiently on display.

Gandering back a year to
http://www1.ietf.org/mail-archive/web/rpsec/current/msg01310.html
shows that Steve Kent was the one who introduced this term and
described his usage of it.  (Though I also hail from Cambridge,
Steve Kent and I might as well have worked for different companies.)

Thanks to all for the other comments, keep 'em coming and I'll try and
sort out how to incorporate them after discussion dies down.

Heading on vacation for a week, though.

Tony

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jul 2006 17:14:27 -0400

>>IP.  It really shows that a MSO author had a hand in writing this.

IP networks transport traffic for subscribers (end users if you wish) 
and they transport traffic that is used by the networks for their own 
management purposes. This text was describing this distinction with 
regard to the scope of security offered by routing security measures. 
If you have other terms that you think do a better job of making this 
distinction by all means offer them, but the distinction is real and 
seems relevant to this document.

Steve

---

From: "Tony Li" <[email-masked]>
Date: Fri, 21 Jul 2006 15:01:17 -0700

> seems relevant to this document.

Many of my IETFish conversations use the terms "control plane" and "data
plane" for control traffic and transit traffic, respectively.

The distinction can sometimes be important when considering control
traffic (e.g., IBGP) that is being forwarded multiple IP hops between
BGP speakers.

Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Jul 2006 18:36:20 -0400

> seems relevant to this document.

IP traffic has been the term used throughout the Internet's history so
why not stick with that.  Subscriber makes no sense in all but recent
contexts.  Subscriber traffic or end user traffic would not include
SNMP for example.  Does a BPG security mechanism protect SNMP traffic?

Of course my next pair of sentences were:

  Please just drop this paragraph.  It is obvious to the intended
  audience that we are not securing IP services.

Do you think it is not obvious to anyone that has any idea what BGP
does that any BGP security mechanism does not do anything for end-user
traffic carried by the router?  If it is *that* obvious why say it.

Curtis

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Jul 2006 14:13:35 -0400

>...

I agree that the term "subscriber" is relatively recent, but the term 
"IP traffic" is not very useful, since network management traffic is 
often carried over IP anyway. When I began working with Internet 
technology in the late 70s I think the phrase we used was "user 
traffic" to distinguish it from net management traffic. However, as 
you noted, we are focusing on only a subset of net management traffic 
anyway.

>traffic carried by the router?  If it is *that* obvious why say it.

The reason for including the text was to emphasize that while BGP 
security enhancement will benefit user traffic, it is not a 
substitute for crypto security applied by the end users. If everyone 
agrees that this is redundant, let's drop it.

Steve