Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03

From: Tony Tauber <[email-masked]>
Date: Mon, 2 Jan 2006 21:06:01 -0800 (PST)

On Mon, 14 Nov 2005, Pekka Savola wrote:

> Hi,
>
> I've read the security requirements document, now that it has a bit
> more detail.  There are a couple of high-level omissions which IMHO
> need to be fixed; there are also some more minor issues in the
> details.  See the comments below.

Hi Pekka,

Your close and thoughtful reading is appreciated, as always.

Sorry it has taken until now to respond and incorporate.

Comments below.

> .....
>
> The most serious shortcoming of this doc is that it does not address
> "economic" realities which is a must for any serious deployment.  In
> particular, you could add for example the following requirements:

Done for both of these.

>
> X.  No Heavy Processing on Routers
>
> Having specialized hardware to deal with cryptography in order to
> get acceptable processing speed is unacceptable in general.  The
> solution cannot be deployed if it requires significant financial
> investment.
>
> In particular, the solution must not require that heavy processing
> is required on all the BGP routers.  Even heavy processing on all
> routers originating a prefix seems very undesirable, as well as
> requiring such in all eBGP routers.  Thus, requiring heavy
> processing in anything except separate network components or one or
> two routers would strongly discourage deployment.
>
> On the other hand, while "low processing on routers" security model
> must be supported, it would be acceptable to have extensions for the
> "basic" support, which could be locally deployed by those parties
> which find it necessary or economically justifiable.
>
> ...
>
> Maybe also something a bit more explicit about the amount of configuration?
>
> X+1.  No Heavy Configuration on Routers
>
> It is undesirable to have long or very detailed configuration on the
> routers, especially it needs to be synchronized on all of them.
> Long configuration makes operating the device more difficult, and
> having to do very detailed configuration may hinder the adoption of
> the security solution; it should be possible to "just start using
> it" if possible.
>
>
> substantial
> -----------
>
>   o  Contents of the UPDATE message SHOULD be authenticated in real-
>      time as the UPDATE message is processed.
> ...
>
>   All BGP implementations that implement security MUST utilize at least
>   one of the above methods for validating routing information.  Real
>   time verification is preferred in order to prevent transitive
>   failures based on periodic or event-driven scan intervals.
>
> ==> you only discuss UPDATEs; you should also mention WITHDRAWs.
> Regardless of whether it's UPDATE or WITHDRAW, you should also
> consider the impact of delaying legitimate routing update (e.g., the
> path went down and the packets will be discarded unless a new path
> is selected ASAP).
>
> (After later reading, some of this is discussed in section 3.4, but an
> appropriate amount of text and a pointer should be added here as well.)
>
>   The AS_PATH for specific prefixes may be protected in any proposed
>   security system in four ways:
> ...
>   All of these checks SHOULD be made available to network operators.
>   Each network operator will decide, on a local basis, which of these
>   checks to enable.
>
> ==> this requirement is not spelled out properly.  At least the last
> one (maybe the second-to-last as well) require mechanisms based on
> the path, i.e., cannot be enabled by local checks.  Are you
> requiring that the transit ASes must implement all of these checks?

No, the requirement that benefit be seen even w/o universal deployment
trumps any suggestion that transit ASes must implement.  If some
iteration through the solution space demonstrates an incongruity, we
can deal with it then.

>   Transport protection is an important aspect of BGP routing
>   protocol security.  The potential to create a linked
>   transport/NLRI/AS_PATH authentication mechanism should not be
>   overlooked and may provide for the accelerated deployment of a BGP
>   security system.  Current security mechanisms for BGP transport
>   (e.g.  TCP-MD5 [4] and GTSM [6]) are inadequate and require
>   significant operator interaction to maintain a respectable level
>   of security.
> ...
>   Any proposed security mechanism MUST include provisions for securing
>   both internal BGP and external BGP peering sessions.
>
> ==> this is not accurate; TCP-MD5 and GTSM are very well adequate.
> That is,
>
> 1) iBGP sessions are prevented if the AS applies source address
> spoofing prevention (or alternatively, blocks access to the select
> parts of the infrastructure components) at its borders; there is no
> need to use TCP-MD5 or GTSM.
>
> 2) eBGP sessions are protected using GTSM when the peer(s) are
> sufficiently trustable.
>
> That leaves only the case when the peering mesh is not
> point-to-point, i.e., ethernet-based internet exchanges.  TCP-MD5 is
> typically used there to protect from session resets by other members
> of the exchange.  The operational pain of TCP-MD5 comes from having
> to agree on static keys on a per-peer basis, but the situation may
> not be much better in terms of config required in any solution.
>
> There are still ICMP attacks to consider
> (draft-gont-tcpm-icmp-attacks-05.txt) but IPsec does not protect
> from those by better.
>
> In any case, the text should be a lot more accurate and realistic,
> and the 'MUST' requirement seems too strong; this might be something
> that should be optional to implement, and certainly optional to
> enable.

We could use a stronger sense of the authenticity of the neighbor, I'd
argue.

> ....
>
>   Key maintenance can be especially onerous for operators.  The
>   number of keys required and the maintenance of keys
>   (update/withdraw/renew) has had an additive effect as a barrier to
>   deployment.  Thus automated means of managing keys, to reduce
>   operational burdens, MUST be available throughout BGP security
>   systems.  These security systems MUST be resistant to compromise
>   of session-level or device-level keys, i.e., the security
>   implications of such compromises MUST be limited.
>
> ==> what are (update/withdraw/renew) keys?  These are not separate
> keys. Just one key is required.

These are actions which one might do with keys.  I'll re-word so that
they don't appear to use the same nomenclature as BGP actions.
Now it reads ..."(issue/revoke/renew)...".

> ==> it might be worth separating the discussion of transport
> protection keys and the route origination (etc.) keys.  These are
> two very different animals with very different security properties.
> For the former, the MUST requirement is way too strong, as you can
> only reset one peering session (and even that only if you get on the
> link) -- hardly a huge problem.

Well, if we just keep on using TCP-MD5 and re-use keys in multiple
places, the implications of compromise can be more widespread.

> semi-editorial
> --------------
>
> ==> the use of upper-case keywords is not appropriate in a
> requirements document like this; please make them lower-case.
>
> ==> section 1.3 does not mention Withdraws?
>
> Update
>      messages are sent between AS peers with the implicit assumption
>      that those messages will be forwarded to others.
>
> ==> this leaves out an important detail: only the best path is
> forwarded (and even then it's only forwarded to those where it's by
> policy configured to be forwarded).

Changed to "...the tacit authorization for those messages to be
forwarded to others"

>      While the AS_PATH information is typically transitive it is,
>      currently, not clearly mandated and many times is removed for
>      various utilitarian reasons.
>
> ==> what do you mean with this?  This sounds as if some operators
> would rewrite long AS paths to shorter one which is (I hope) not
> true...  Reword?

s/removed/modified/

>      Specifications state that the AS routing graph MUST be loop
>      free.  This indicates that UPDATES received from an external
>      peer which contain the local AS will be rejected.
>
> ==> on idr list, maybe about a year ago, this topic came up, and at
> least some people seemed to think that such routes need not be
> rejected, but it is sufficient that they are of lower preference
> than anything else.  The "valid" case for these was during certain
> network partitions.  Not that I personally bought it, but that's a
> separate story....
>
>      Prepending a peer AS number on inbound UPDATEs is employed for
>      biasing internal routing and forwarding management while
>      prepending one's own AS number on outbound advertisement is
>      typically used to bias forwarding and routing changes in
>      external networks.  The latter practice is explicitly permitted
>      by the BGP specification while the former is not.
>
> ==> please add an explicit reference which states how the former is
> not permitted.

It's not explicitly permitted, so, by definition, no reference exists
to say so.

>      Some operators, insert a remote AS number in an UPDATE, in
>      order to cause the UPDATE to be dropped by that AS so that
>      traffic will not traverse a given path.
>
> ==> remove the commas; reference (a nanog presentation/posts, a
> paper, ...) would be useful here.

I agree, but regretably I haven't been able to find anything "on the
record".

>   Attributes such as LOCAL_PREF are not transitive and,
>   as such, are protected by BGP session security.
>
> ==> local_pref is only passed between iBGP, so if you want to be
> more generic, I'd use MED as an example.

Done.

>   o  AS_PATH Feasibility Check: The AS_PATH list MUST correspond to a
>      valid list of autonomous systems according to the first
>      verification category listed in the "Areas to Secure" Section
>      above.
>
>   o  Update Transit Check: Routing information carried through BGP
>      SHOULD include information that can be used to verify the
>      readvertisement or modification by each autonomous system through
>      which the UPDATE has passed.  This check is somewhat more rigorous
>      than the "verifiable list of autonomous systems" above.
>
> ==> you don't list the "verifiable list of autonomous system"; did
> you mean the feasibility check or something else?

Changed to make the wording agree.

>   o  A BGP speaker and listener have chosen to restrict the number of
>      received prefixes for the listener.  The listener has chosen to
>      honor route announcements sent in a summary fashion by the
>      speaker.
>
> ==> it's not clear what you're trying to say here, and it's no clear
> who is the "speaker" and who is the "listener". please reword.
>
> 12.  References
>
> ==> split to informative and normative.

Done.

> editorial
> ---------

Did all of these.  Thanks!

See the revision:

http://www.1-4-5.net/~ttauber/draft-ietf-rpsec-bgpsecrec-04.txt

and, for diffs between the two versions:

http://www.1-4-5.net/~ttauber/draft-ietf-rpsec-bgpsecrec-03-04-diff.html

Tony

> ==> you should add ToC as the draft is over 15 pages.
>
> ==> you should maybe use <?rfc compact='yes'?><?rfc subcompact='no'?>
>
> ==> slightly trimming the abstract would allow it to be on the cover page:)
>
>  specification,RFC4271 [7], as a path-vector routing protocol.  BGP
>
> ==> s/,R/, R/
>
>  The session between two BGP speakers can be secured such that the BGP
>   data received by the BGP speakers can by cryptographically verified
>   to have been transmitted by the peer BGP speaker and not a replay of
>   previously transmitted legitimate data.
>
> ==> s/by/be/
>
>      orignation information is removed (i.e. the more-specific
>
> ==> s/orig/origi/

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Jan 2006 10:32:23 -0500

Tony,

I have some comments on your response to Pekka's comments.  Since I 
saw no response to Pekka's original message I did not bother 
addressing all of his comments when they first appears around the 
holidays. But, if you plan on making changes to the document in 
response to these comments ...

>>solution cannot be deployed if it requires significant financial

In what time frame? If we said that no changes that require 
"significant" financial investments can ever be made, then we would 
have to declare many changes, security or otherwise, to be 
unacceptable.

>>two routers would strongly discourage deployment.

"heavy processing" is a vague term. I realize that it's hard to be 
precise when discussing these issues, but vague wording only leads to 
later arguments. Also, different ISPs probably have deployed 
different routers for eBGP, so what may be heavy processing for one 
ISP may not be for another, or may not be for a different eBGP router 
within the same ISP.

>>which find it necessary or economically justifiable.

This notion sounds attractive in the abstract, but there is no 
indication that it is achievable, at the level of abstraction used to 
describe it.  Routing security is a distributed function. While we 
all agree that incremental deployment is a requirement, it is not 
clear that support of different security "models" by different ISPs 
yields coherent solution.

>>the security solution; it should be possible to "just start using

I agree that it is desirable to minimize the additional configuration 
that a router will require for security purposes. On the other hand, 
auto-configuration is not likely to be a realistic option here, just 
as it has not been achieved in any context where secure, 
externally-imposed identification is required. Also, depending on the 
availability of configuration tools, even very detailed configuration 
data may be manageable, especially if that data is derivable from 
other data already used for router config.

>>path went down and the packets will be discarded unless a new path

Explicit route withdrawal is effected through an UPDATE message, so I 
am a bit puzzled by your comment here.

>>==> this is not accurate; TCP-MD5 and GTSM are very well adequate.

TCPMD5 is not adequate in several ways.  The specific crypto method 
employed is poor, relative to modern techniques. Also the lack of 
automated key management makes it likely that the keys are rarely 
changed and thus increasingly vulnerable.

>>need to use TCP-MD5 or GTSM.

"iBGP session are prevented?" what does that mean in this context?

>>2) eBGP sessions are protected using GTSM when the peer(s) are

this statement ignores the possibility of active wiretapping, so it 
is not just the peers that need to be trusted, it is also the 
communication media context.

>>not be much better in terms of config required in any solution.

not true. if, for example, one were to use IPsec and IKE, then each 
router would have to be configured with one cert, not one secret key 
per peer.

>>(draft-gont-tcpm-icmp-attacks-05.txt) but IPsec does not protect

IPsec offers specific access control measures for dealing with ICMP 
traffic, so I am not sure what you mean here.

>Now it reads ..."(issue/revoke/renew)...".

I agree with Pekka that the wording above is confusing.

>places, the implications of compromise can be more widespread.

I agree with Pekka that we need to discuss keys used for 
point-to-point session protection separately from keys used for 
transitive route (UPDATE) protection. In a detailed sense, the former 
will usually be symmetric keys, perhaps derived from a DH exchange, 
but in any case of only local significance. The latter are probably 
asymmetric key pairs with global significance.

>>network partitions.  Not that I personally bought it, but that's a

the current BGP spec (in the RFC editor's queue) does not relax the 
loop-free requirement, so I think it still belongs here.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Jan 2006 21:36:46 +0200 (EET)

On Wed, 11 Jan 2006, Stephen Kent wrote:
> In what time frame? If we said that no changes that require "significant" 
> financial investments can ever be made, then we would have to declare many 
> changes, security or otherwise, to be unacceptable.

One could rephrase, ".. investment that would not be otherwise 
required."

Routers do get replaced with newer versions over time for various 
reasons, and if the newer versions support cryptography to sufficient 
degree out to the box without significant extra investment compared to 
non-cryptographic hardware, that's fine.  We just shouldn't be 
requiring fork-lift upgrades to get crypto.

> "heavy processing" is a vague term. I realize that it's hard to be precise 
> when discussing these issues, but vague wording only leads to later 
> arguments. Also, different ISPs probably have deployed different routers for 
> eBGP, so what may be heavy processing for one ISP may not be for another, or 
> may not be for a different eBGP router within the same ISP.

All this is very true, of course.  But I'm not sure if we could draw 
up precise requirements .. the only way I can personally see here is 
leave it somewhat vague and when we're evaluating the solution(s) as a 
whole (considering all the requirements) make a decision whether it 
seems too heavy or not given the processing power situation at that 
point in time.

Maybe some metrics could be included, but I fear that would be a nice 
rathole for lengthy and oft-revised discussions if we did so..

> This notion sounds attractive in the abstract, but there is no indication 
> that it is achievable, at the level of abstraction used to describe it. 
> Routing security is a distributed function. While we all agree that 
> incremental deployment is a requirement, it is not clear that support of 
> different security "models" by different ISPs yields coherent solution.

Certainly, I'm doubtful that any reasonable solution could fulfill all 
the requirements we place forward (because then it would be too 
complex ;-), therefore I'd like to call them "goals" and try to make 
it clear enough which ones are more important than others.

I'm rather sure that solutions for the aforementioned model could 
exist though -- the question just is which current requirements would 
need to be bent to accommodate that.

We just don't know this before we know this direction has been 
suitably well explored.

> I agree that it is desirable to minimize the additional 
> configuration that a router will require for security purposes. On 
> the other hand, auto-configuration is not likely to be a realistic 
> option here, just as it has not been achieved in any context where 
> secure, externally-imposed identification is required. Also, 
> depending on the availability of configuration tools, even very 
> detailed configuration data may be manageable, especially if that 
> data is derivable from other data already used for router config.

I agree that it's unfeasible to look for complete auto-configuration. 
Maybe the last sentence could be toned down a bit -- e.g., by removing 
everything after ";" or rewording it in some way to not be 
over-optimistic.

I just want to avoid the situation where a lot of configuration (like 
over a couple of dozen of lines, multiplied by the number of routers) 
would need to be maintained, especially if the information is highly 
dynamic.

Analogue: a reason why RPS hasn't been easily deployable is that the 
prefix list (or even AS path list) config on routers takes hundreds, 
thousands or tens of thousands of lines of config and is highly 
dynamic.  We don't want to go anywhere near that kind of situation.

> Explicit route withdrawal is effected through an UPDATE message, so I am a 
> bit puzzled by your comment here.

True, apparently I was confused here, and was thinking too much ahead 
of "BGP Update - Withdraw" vs "BGP Update - advertise the next best 
path".

> TCPMD5 is not adequate in several ways.  The specific crypto method employed 
> is poor, relative to modern techniques. Also the lack of automated key 
> management makes it likely that the keys are rarely changed and thus 
> increasingly vulnerable.

This depends a lot on your trust model, as discussed below.  Maybe 
this needs to be spelled out better, so the readers can make their own 
judgment based on their own assumptions.

> "iBGP session are prevented?" what does that mean in this context?

_Disrupting_ iBGP sessions, sorry that I missed the word :)

> this statement ignores the possibility of active wiretapping, so it is not 
> just the peers that need to be trusted, it is also the communication media 
> context.

Correct, but this depends a lot on your trust model. I don't consider 
this a major threat in our network for example.  If lower layer 
attacks are deemed to be a problem, I think most attacks can be 
carried out much more easily without BGP at all just.

In any case, maybe it would make sense to try to break out the text a 
bit depending on what kind of threat model you have beyond BGP.

(It's obvious that there are easy solutions to this problem, but my 
point is that many people may not want to mandate them because they 
don't see the point.)

> not true. if, for example, one were to use IPsec and IKE, then each router 
> would have to be configured with one cert, not one secret key per peer.

One cert would be enough for your own routers.  What about N peer 
routers in other administrative domain which you have BGP session to? 
Would you also need to certify those under that cert?

> IPsec offers specific access control measures for dealing with ICMP traffic, 
> so I am not sure what you mean here.

Valid ICMP messages can be originated by parties which you don't share 
security associations with.  IPsec does not deal with this situation 
very well.  AFAICT, it's either "ignore everything that you haven't 
established an SA for" (which I argue is unrealistic in most 
scenarios) or accept everything.

> the current BGP spec (in the RFC editor's queue) does not relax the loop-free 
> requirement, so I think it still belongs here.

Agreed.

(It seems the new BGP spec strengthened the language around this, so 
now section 9.1.2 forbids considering these routes.  In RFC1771, this 
was described in section 9.3 in a more liberal manner like I mention 
above.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Jan 2006 18:24:22 -0500

Pekka,

>>...
>
>One could rephrase, ".. investment that would not be otherwise required."
>
>reasons, and if the newer versions support cryptography to 
>sufficient degree out to the box without significant extra 
>investment compared to non-cryptographic hardware, that's fine.  We 
>just shouldn't be requiring fork-lift upgrades to get crypto.

I understand your reasoning, but even this seems tricky. What if some 
routers can support crypto using software because the UPDATE 
frequency is low enough for where they are used, but other routers 
cannot? Is the criteria that if any router anywhere in the Internet 
has to be replaced in order support a proposed security technology 
then that technology is unsuitable?

>leave it somewhat vague and when we're evaluating the solution(s) as 
>a whole (considering all the requirements) make a decision whether 
>it seems too heavy or not given the processing power situation at 
>that point in time.
>
>Maybe some metrics could be included, but I fear that would be a 
>nice rathole for lengthy and oft-revised discussions if we did so..

yes, I think this is hard to quantify. by making it a (vague) 
requirement we create a basis for endless debate :-)

>>indication that it is achievable, at the level of abstraction used 
>>to describe it. Routing security is a distributed function. While 
>>we all agree that incremental deployment is a requirement, it is 
>>not clear that support of different security "models" by different 
>>ISPs yields coherent solution.
>
>Certainly, I'm doubtful that any reasonable solution could fulfill 
>all the requirements we place forward (because then it would be too 

I think it does make sense to distinguish between goals and 
requirements when we agree on which things fall into which category.

>>...
>
>I agree that it's unfeasible to look for complete 
>auto-configuration. Maybe the last sentence could be toned down a 
>bit -- e.g., by removing everything after ";" or rewording it in 
>some way to not be over-optimistic.
>
>I just want to avoid the situation where a lot of configuration 
>(like over a couple of dozen of lines, multiplied by the number of 
>routers) would need to be maintained, especially if the information 
>is highly dynamic.

agreed. config info needs to be "manageable" and that requires paying 
attention to what is fairly static and what changes often.

>dynamic.  We don't want to go anywhere near that kind of situation.

good example.

>>...
>
>True, apparently I was confused here, and was thinking too much 
>ahead of "BGP Update - Withdraw" vs "BGP Update - advertise the next 
>best path".

OK.

>this needs to be spelled out better, so the readers can make their 
>own judgment based on their own assumptions.

I personally hate the term "trust model" in general, and in this case 
it's not applicable. the issue is the threat model, i.e., what do you 
believe your adversaries want to accomplish and what attacks are they 
capable of launching to achieve their goals.

>...
>Correct, but this depends a lot on your trust model. I don't 
>consider this a major threat in our network for example.  If lower 
>layer attacks are deemed to be a problem, I think most attacks can 
>be carried out much more easily without BGP at all just.
>
>In any case, maybe it would make sense to try to break out the text 
>a bit depending on what kind of threat model you have beyond BGP.

right, threat model, not trust model.

>routers in other administrative domain which you have BGP session 
>to? Would you also need to certify those under that cert?

you would not certify routers with which you peer. you validate their 
certs, which they can pass to you, or which are download to you by 
your NOC. for example, if one uses IPsec for session security, IKE 
typically passes certs at the time of security association 
establishment, to allow each peer to authenticate the identity of the 
other. In this context it is probably less important to know a 
router's ID in an authentic fashion, and more important to know what 
AS is represents (getting back to your minimizing config info point).

>>...
>
>Valid ICMP messages can be originated by parties which you don't 
>share security associations with.  IPsec does not deal with this 
>situation very well.  AFAICT, it's either "ignore everything that 
>you haven't established an SA for" (which I argue is unrealistic in 
>most scenarios) or accept everything.

Not quite true. IPsec (as of RFC 4301) has special provisions for 
ICMP, especially ICMP error messages.

>now section 9.1.2 forbids considering these routes.  In RFC1771, 
>this was described in section 9.3 in a more liberal manner like I 
>mention above.)
>

OK.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 12 Jan 2006 08:20:31 -0500

> "significant" financial investments can ever be made, then we would have 
> to declare many changes, security or otherwise, to be unacceptable.

Typical rollout time, today, is about 7 years, for any new equipment. I 
believe that time is getting longer, however, and we will probably see 
times in the ten to fifteen year range in the next 7 years--in other 
words, I suspect that at least some of the equipment currently running 
for three to four years will not be replaced until 8 to 9 years from now.

As for the remainder--I don't know how to define "low processing 
requirements" and "high processing requirements." I tend to prefer the 
wording "should be able to process on existing midrange equipment, or 
offloaded to some outside box," myself. But, for some reason, I seem to 
remember the WG rejecting "offloading" at some point.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Jan 2006 09:59:57 -0500

On Thu, Jan 12, 2006 at 08:20:31AM -0500, Russ White wrote:
> But, for some reason, I seem to 

I don't actually remember that.  For some types of operations, I think
it is an interesting idea.

-- 
Jeff Haas 
NextHop Technologies

---

From: Pekka Savola <[email-masked]>
Date: Sun, 15 Jan 2006 18:45:39 +0200 (EET)

(I have cut off parts inline where I we agree or otherwise I don't 
think more needs to be said.)

On Wed, 11 Jan 2006, Stephen Kent wrote:
>> Routers do get replaced with newer versions over time for various reasons, 
>> and if the newer versions support cryptography to sufficient degree out to 
>> the box without significant extra investment compared to non-cryptographic 
>> hardware, that's fine.  We just shouldn't be requiring fork-lift upgrades 
>> to get crypto.
>
> I understand your reasoning, but even this seems tricky. What if some routers 
> can support crypto using software because the UPDATE frequency is low enough 
> for where they are used, but other routers cannot? Is the criteria that if 
> any router anywhere in the Internet has to be replaced in order support a 
> proposed security technology then that technology is unsuitable?

This would need to be left as a judgment call when evaluating the 
tradeoffs a solution makes, I think.

FWIW, it's clear that in some topologies, (e.g., when talking about 
the number of prefixes in hundreds), S/W approaches would be 
acceptable, but in most of those scenarios, the existing mechanisms 
(e.g., prefix filtering) are also applicable.

UPDATE frequency as such doesn't help much.  You need to consider the 
protential update frequency -- e.g., what would happen if the session 
was reset or flapping and basically all the prefixes would need to be 
processed at once one or more times.

So, if you think that'd help, one could rephrase this for example as 
follows:

=======

Having specialized hardware to deal with cryptography in order to get 
acceptable processing speed is unacceptable in general.  The solution 
cannot be deployed if it requires significant financial investment 
that would not be otherwise required.

While software mechanisms may be sufficient when the number of 
prefixes a router needs to process is not much higher than O(100), 
it's unprobable that such approaches could scale with richer 
interconnection of at least O(10,000) prefixes.
=======

>>> ...
>> 
>> All this is very true, of course.  But I'm not sure if we could draw up 
>> precise requirements .. the only way I can personally see here is leave it 
>> somewhat vague and when we're evaluating the solution(s) as a whole 
>> (considering all the requirements) make a decision whether it seems too 
>> heavy or not given the processing power situation at that point in time.
>> 
> yes, I think this is hard to quantify. by making it a (vague) requirement we 
> create a basis for endless debate :-)

Endless debate will ensue in any case if the group(s) cannot get to 
rough consensus.  If the group can, this shouldn't be too big a 
problem.  I'm more concerned about an endless debate that could ensue 
from trying to fine-tune the metrics :)

>> I agree that it's unfeasible to look for complete auto-configuration. Maybe 
>> the last sentence could be toned down a bit -- e.g., by removing everything 
>> after ";" or rewording it in some way to not be over-optimistic.
>> 
>> I just want to avoid the situation where a lot of configuration (like over 
>> a couple of dozen of lines, multiplied by the number of routers) would need 
>> to be maintained, especially if the information is highly dynamic.
>

No disagreement here.  Maybe some of that should be reflected in the 
text somehow.

>>> ...
>> 
>> One cert would be enough for your own routers.  What about N peer routers 
>> in other administrative domain which you have BGP session to? Would you 
>> also need to certify those under that cert?
>
> you would not certify routers with which you peer. you validate their certs, 
> which they can pass to you, or which are download to you by your NOC. for 
> example, if one uses IPsec for session security, IKE typically passes certs 
> at the time of security association establishment, to allow each peer to 
> authenticate the identity of the other. In this context it is probably less 
> important to know a router's ID in an authentic fashion, and more important 
> to know what AS is represents (getting back to your minimizing config info 
> point).

But assuming you don't have a common trust anchor with your and all 
your peers' certificates, you'll need to keep at least some (local) 
data on which certs you find acceptable.  I don't know well enough 
what's needed, whether there would be issues with rollovers, whether 
you'd need deal with CRL-like situations, etc. -- but with N peers 
(where N is a non-trivial number), this seems somewhat comparable 
administrative complexity to managing TCP-MD5 keys if the MD5 keys are 
never changed.

I'd like to emphasize that I wouldn't want to keep that information on 
the routers, at least if the operator doesn't want to do that. 
AFAICT, you'll need to set up something on a per-peer basis.

>> security associations with.  IPsec does not deal with this situation very 
>> well.  AFAICT, it's either "ignore everything that you haven't established 
>> an SA for" (which I argue is unrealistic in most scenarios) or accept 
>> everything.
>
> Not quite true. IPsec (as of RFC 4301) has special provisions for ICMP, 
> especially ICMP error messages.

My point was that vanilla TCP and TCP-MD5 as written are almost 
equally vulnerable to ICMP error message attacks. 
Draft-gont-tcpm-icmp-attacks-05 (soon under draft-ietf-tcpm) provides 
methods to make them more robust.

IPsec does not really seem to provide even the same level of 
verification of ICMP error messages as that draft.  RFC 4301 mainly 
focuses on requiring that the implementations must have configurable 
options which type/code etc ICMPs to listen to and which to discard. 
This is my reading of section 6.1 of RFC 4301.  Section 6.2 (which 
provides a bit more checking) doesn't seem to apply in this situation 
very well assuming you don't configure an ICMP SAs for all the peers 
and ignore other ICMP errors.

Hence, I don't see how IPsec would give additional protection against 
ICMP errors compared to non-IPsec TCP (w/ 
draft-gont-tcpm-icmp-attacks-05 checks).  The protection might very 
well be even worse by default.

....

So, if you're not worried about threats on the transmission media the 
BGP session runs over, GTSM, draft-gont-tcpm-icmp-attacks-05, and to a 
lesser degree TCP-MD5 -like techniques may very well be very close to 
satisfying the security requirements of the peering sessions 
themselves.  Thus the main focus should be on the 
authentication/authorization aspects of the contents of the 
advertisements.

But we likely disagree on this.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jan 2006 13:55:52 -0500

Pekka,

>>>...
>>
>>I understand your reasoning, but even this seems tricky. What if 
>>some routers can support crypto using software because the UPDATE 

agreed, which is why I think it makes sense to consider these 
(necessarily) vague considerations as goals, but not requirements.

>(e.g., prefix filtering) are also applicable.

I would characterize the issue differently. In some topologies one 
can use prefix filters because the range of prefixes that should be 
accepted from some peers is fairly static and thus there is no need 
to expend energy on crypto verification of the signatures. This is 
true no matter how many prefixes are involved. This does, however, 
require good tools to manage the prefix filter generation.  The cost 
of signature verification does not grow as the number or prefixes in 
an UPDATE grows. It grows based on the number of hops in the path 
being validated.

>UPDATE frequency as such doesn't help much.  You need to consider 
>the protential update frequency -- e.g., what would happen if the 
>session was reset or flapping and basically all the prefixes would 
>need to be processed at once one or more times.

When I said UPDATE frequency I was considering this as well. When a 
session is reset and one receives a lot of UPDATEs from a peer, it is 
not necessary to verify the signatures on all of them, if one uses a 
mechanism based on signed UPDATEs. One shoud look at each UPDATE and 
ask "if this UPDATE is authentic, does it cause me to change my 
LocRIB?" If the answer is no, then there is no need to peform crypto 
verification on the UPDATE at that time.

>
>So, if you think that'd help, one could rephrase this for example as follows:
>
>=======
>investment that would not be otherwise required.
>

As I noted above, the number of prefixes is not, per se, the 
determining  factor. Thus the second paragraph is not a good way to 
characterize the issue.

>problem.  I'm more concerned about an endless debate that could 
>ensue from trying to fine-tune the metrics :)

but introducing these metrics is already a source of such debate, and 
it creates the need to refine them if we're going to put them into 
the document, especially as requirements.

>administrative complexity to managing TCP-MD5 keys if the MD5 keys 
>are never changed.

If you don't have a PKI to manage certs, then certs are not 
appropriate for this sort of context. Note that efforts are now 
beginning to establish a PKI for address and AS number allocation, 
starting at the RIR level. (The proposed PKI uses RFC 3779 extensions 
to represent address blocks and AS numbers.)  The AS number part is 
much easier than the address allocation part, because there are fewer 
discrete allocations, and they are effected only by registries. With 
certs issued by the registries to AS number holders, ISPs can issue 
certs to routers and it is easy to tell if a router is authorized to 
represent a specific AS. That PKI, if it is successful, would address 
the trust anchor concern you cite above.

>I'd like to emphasize that I wouldn't want to keep that information 
>on the routers, at least if the operator doesn't want to do that. 

Well, if the PKI I mentioned is deployed, a router with access to the 
root public key could verify the cert chain that terminates with a 
given router's cert. Such a chain would be fairly short: 
root->RIR->ISP or root->RIR->NIR/LIR->ISP. But, an operator could 
choose other ways to deal with this, e.g., distribute the CA cert for 
a each AS to the routers that are configured to peer with that AS, to 
create a 1-step chain for router cert verification, for example.

>Draft-gont-tcpm-icmp-attacks-05 (soon under draft-ietf-tcpm) 
>provides methods to make them more robust.
>
>provides a bit more checking) doesn't seem to apply in this 
>situation very well assuming you don't configure an ICMP SAs for all 
>the peers and ignore other ICMP errors.

Yes, these are the relevant sections of 4301, but they have to be 
read in the context of the access control mechanisms that IPsec 
already provides. IPsec allows you to filter ICMP error messages, to 
make sure that they come from a source consistent with the claimed 
address to which they refer in the payload. It also suggests controls 
to allow you to reject ICMP messages that try to set a PMTU to a size 
below a threshold established for a peer (6.1.1, top of page 64).

>Hence, I don't see how IPsec would give additional protection 
>against ICMP errors compared to non-IPsec TCP (w/ 

When IPsec is introduced, it create a barrier that ALL traffic must 
traverse. In a router, this barrier could be established around the 
router's management host and thus would process any traffic, 
including ICMP traffic, directed to that internal host.  In the 
typical, not-multi-hop BGP peering case, you would accept ICMP error 
messages relevant to the BGP TCP session to come only from the peer 
router, and thus they can be authenticated, and filtered.

>....
>
>So, if you're not worried about threats on the transmission media 
>the BGP session runs over, GTSM, draft-gont-tcpm-icmp-attacks-05, 
>and to a lesser degree TCP-MD5 -like techniques may very well be 
>very close to satisfying the security requirements of the peering 
>sessions themselves.  Thus the main focus should be on the 

I would disagree that it is safe, in general, to ignore attacks 
against links between routers.  GTSM is clever, but fails in the 
context of such attacks. The existing TCP-MD5 checksum is poor 
cryptographically, but the bigger problem is the lack of automated 
key management capability. I think it is reasonable to start by 
addressing peering session security, on a point-to-point basis, the 
move on to the harder, transitive security issues associated with 
advertisements.

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 18 Jan 2006 18:53:29 -0500

> (necessarily) vague considerations as goals, but not requirements.

Hmmm... I would think that if this is something that's required for any 
system to have a realistic opportunity of actually being deployed, then 
it's still at least a SHOULD. Perfectly undeployable perfect systems are 
not really solutions at all. :-)

> mechanism based on signed UPDATEs. One shoud look at each UPDATE and ask 
> "if this UPDATE is authentic, does it cause me to change my LocRIB?" If 
> the answer is no, then there is no need to peform crypto verification on 
> the UPDATE at that time.

If you lose a peer, you have to clear your RIB for all information 
previously received from that peer, receive all updates, and then 
reinstall all of them into your RIB. It's not always clear when an 
update will change you RIB or not--there's no implementation I know of 
that evaluates whether or not a route would win if installed before 
processing the route, they all choose their best route, and attempt to 
install the route, seeing if it actually is installed when the attempt 
is completed. (I know, just a nit, but the closer we are to reality in 
our understanding of how implementations actually work, the closer we 
can mold requirements so they will be do-able in the real world).

:-)

Russ

- --

---

From: Stefan Mink <[email-masked]>
Date: Thu, 19 Jan 2006 09:53:40 +0100

Russ,

Russ White wrote:
> reinstall all of them into your RIB. 

what about graceful restart for BGP?

   tschuess
             Stefan
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 09:48:34 -0500

Russ,

>not really solutions at all. :-)

yes, but vague comments about performance and manageability are just 
fodder for debate, not objective metrics that should be described as 
"requirements." :-)

>can mold requirements so they will be do-able in the real world).

Which RIB?

The AdjRIB for the peer in question can be populated with unverified 
advertisements safely, so long as no unverified routes are selected 
for use in the LocRIB. When a route is selected as the "best" for the 
NLRI in question, then it needs to be verified before it can be used 
safely.

What aspect of this heuristic do you feel is inconsistent with how 
implementations actually work?

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 10:15:32 -0500

> what about graceful restart for BGP?

Certainly, but that's not the "normal" mode of BGP operation. Perhaps, 
in 5 or 6 years, when it's "commonly deployed," we can assume GR is the 
normal mode of operation. Today, I don't think you can.

:-)

Russ

- --

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 19 Jan 2006 10:16:26 -0500

Stefan,

> what about graceful restart for BGP?

In graceful restart, you (often) start with no RIB.  You seed the
RIB with the FIB and then stale out RIB entries once your protocol
has resynchronized.

-- 
Jeff Haas 
NextHop Technologies

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 10:25:53 -0500

> fodder for debate, not objective metrics that should be described as 

Just because something isn't easy to define doesn't mean it's not a 
requirement, IMHO. :-)

>> can mold requirements so they will be do-able in the real world).

The RIB is the table from which forwarding information is drawn whether 
for forwarding or for building forwarding tables.

> advertisements safely, so long as no unverified routes are selected for 
> use in the LocRIB. When a route is selected as the "best" for the NLRI 
> in question, then it needs to be verified before it can be used safely.
> 

There's no such things as an AdjRIB in any implementation of BGP that 
I'm aware of--well, you might want to count the soft reset tables in 
Cisco IOS as an "adjrib," but, in reality, we (Cisco) strongly suggest 
customers not to use that feature at all, but rely on route refresh, 
instead. In fact, I'm not aware of a single BGP implementation that 
strictly follows the model implementation described in the BGP 
specification(s).

Routers don't just run one protocol, as the BGP specifications assume. 
In fact, a single BGP process may not populate a single RIB.

:-)

Russ

- --

---

From: Stefan Mink <[email-masked]>
Date: Thu, 19 Jan 2006 16:44:13 +0100

> RIB with the FIB and then stale out RIB entries once your protocol

ok, depending on the site you're looking at: the partner staying
alive and seeing the neighbors control plane going down and coming
up again AFAIK sustains his RIB and in this case would not have to
authenticate each route again, if its still in the RIB (and thus
was checked in the past), does he?

   tschuess
             Stefan

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 19 Jan 2006 10:58:49 -0500

> was checked in the past), does he?

I'd expect so.

If the question you're asking is "Could Graceful Restart be extended
to allow a lower impact on a restarting router", I think that the
answer is "maybe".  

Let's agree how to secure things outside of restart context first. 

-- 
Jeff Haas 
NextHop Technologies

---

From: Stefan Mink <[email-masked]>
Date: Thu, 19 Jan 2006 17:04:56 +0100

> Let's agree how to secure things outside of restart context first. 

ACK

   tschuess
             Stefan

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 11:11:36 -0500

>Just because something isn't easy to define doesn't mean it's not a

Requirements need to be objectively testable to be useful. So, "easy 
to define" is not show stopper, but impossible to define in an 
objective, testable fashion is.

So far the discussion yielded wording for these criteria that are 
objectively testable, and not simultaneously silly. So, for example, 
a simple statement like "Any security mechanism MUST/SHOULD NOT 
degrade router performance" is objectively testable, but its also 
silly; years of experience indicate that the introduction of any just 
about security mechanism in any computing or communication 
environment will add some overhead.

>strictly follows the model implementation described in the BGP

I asked the question because the BGP spec (RFC  4271) specifically 
distinguishes AdjRIBs from the LocRIB as part of the model for BGP 
operation. A compliant implementation must behave in a fashion 
consistent with this abstract model, irrespective of how the 
functions are implemented.

However you implement BGP, there still needs to be a distinction 
between an advertisement from a peer that is NOT the best route for a 
given set of NLRI at the time the advertisement is received, but 
which still needs to be maintained in case the current best route is 
withdrawn. One also needs to mark each route based on which peer 
advertised it, to ensure than only the peer that advertised the route 
can withdraw it. Given these requirements, it is still possible to do 
what I described, i.e., don't spend time validating a route which 
does not appear to be the best route for a given set of NLRI.

Steve

---

From: Paul Jakma <[email-masked]>
Date: Thu, 19 Jan 2006 17:13:26 +0000 (GMT)

On Thu, 19 Jan 2006, Stephen Kent wrote:

> yes, but vague comments about performance and manageability are just fodder 
> for debate, not objective metrics that should be described as "requirements." 
> :-)

Indeed, agreed. Pekka's original comment though did point at a better 
definition though:

" In particular, the solution must not require that heavy processing
   is required on all the BGP routers."

I.e. I think the key point here is "on all the BGP routers" - not to 
define 'heavy processing' (lets ignore degree of 'heavy' as you 
suggest).

Whether "on all" is or is not acceptable is the key. Some people 
might prefer it not to be acceptable and hence have the requirements 
allow for a solution in which the crypto-load can be off-loaded and 
confined to a subset of routers.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The meek don't want it.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Jan 2006 19:30:15 +0200 (EET)

On Wed, 18 Jan 2006, Stephen Kent wrote:
> When I said UPDATE frequency I was considering this as well. When a session 
> is reset and one receives a lot of UPDATEs from a peer, it is not necessary 
> to verify the signatures on all of them, if one uses a mechanism based on 
> signed UPDATEs. One shoud look at each UPDATE and ask "if this UPDATE is 
> authentic, does it cause me to change my LocRIB?" If the answer is no, then 
> there is no need to peform crypto verification on the UPDATE at that time.

I'd say that in most cases the answer would be "yes".  The whole point 
of peering (unless the link is acting as a cold backup) is to accept 
prefixes.  Operators also tend to set preferences in the incoming 
advertisements, making them preferable.

When such sessions (with 1,000-200,000 "yes, loc-rib update would be 
needed" prefixes) flap, the resulting computation could be rather 
intensive.

>> Endless debate will ensue in any case if the group(s) cannot get to rough 
>> consensus.  If the group can, this shouldn't be too big a problem.  I'm 
>> more concerned about an endless debate that could ensue from trying to 
>> fine-tune the metrics :)
>
> but introducing these metrics is already a source of such debate, and it 
> creates the need to refine them if we're going to put them into the document, 
> especially as requirements.

I maintain these issues are vital for deployment, but I don't think 
it's productive to continue this discussion in this thread.

>> But assuming you don't have a common trust anchor with your and all your 
>> peers' certificates, you'll need to keep at least some (local) data on 
>> which certs you find acceptable.  I don't know well enough what's needed, 
>> whether there would be issues with rollovers, whether you'd need deal with 
>> CRL-like situations, etc. -- but with N peers (where N is a non-trivial 
>> number), this seems somewhat comparable administrative complexity to 
>> managing TCP-MD5 keys if the MD5 keys are never changed.
>
> If you don't have a PKI to manage certs, then certs are not appropriate for 
> this sort of context. Note that efforts are now beginning to establish a PKI 
> for address and AS number allocation, starting at the RIR level. (The 
> proposed PKI uses RFC 3779 extensions to represent address blocks and AS 
> numbers.)  The AS number part is much easier than the address allocation 
> part, because there are fewer discrete allocations, and they are effected 
> only by registries. With certs issued by the registries to AS number holders, 
> ISPs can issue certs to routers and it is easy to tell if a router is 
> authorized to represent a specific AS. That PKI, if it is successful, would 
> address the trust anchor concern you cite above.

Such PKIs would certainly simplify a number of things, but it's not 
clear yet how successful they are going to be.  If we are going to 
depend on them in the design, the requirements could possibly say a 
few words on whether that kind of dependency is acceptable or not.

>> IPsec does not really seem to provide even the same level of verification 
>> of ICMP error messages as that draft.  RFC 4301 mainly focuses on requiring 
>> that the implementations must have configurable options which type/code etc 
>> ICMPs to listen to and which to discard. This is my reading of section 6.1 
>> of RFC 4301.  Section 6.2 (which provides a bit more checking) doesn't seem 
>> to apply in this situation very well assuming you don't configure an ICMP 
>> SAs for all the peers and ignore other ICMP errors.
>
> Yes, these are the relevant sections of 4301, but they have to be read in the 
> context of the access control mechanisms that IPsec already provides. IPsec 
> allows you to filter ICMP error messages, to make sure that they come from a 
> source consistent with the claimed address to which they refer in the 
> payload.

Could you quote the specific text in RFC 4301 Section 6 that specifies 
this?  I can't seem to find it.

>> Hence, I don't see how IPsec would give additional protection against ICMP 
>> errors compared to non-IPsec TCP (w/ draft-gont-tcpm-icmp-attacks-05 
>> checks).  The protection might very well be even worse by default.
>
> When IPsec is introduced, it create a barrier that ALL traffic must traverse. 
> In a router, this barrier could be established around the router's management 
> host and thus would process any traffic, including ICMP traffic, directed to 
> that internal host.  In the typical, not-multi-hop BGP peering case, you 
> would accept ICMP error messages relevant to the BGP TCP session to come only 
> from the peer router, and thus they can be authenticated, and filtered.

ICMP error messages must be accepted from anywhere, with any source 
address.  While the only ICMP error messages relevant to such a BGP 
TCP session would need to come from your peer, you'd need to have 
verification checks in the ICMP processing code that deals with this 
case when the ICMP error carries only an IP header and 8 bytes of 
payload.  At the moment, I haven't been able to locate this text in 
RFC 4301.

> I would disagree that it is safe, in general, to ignore attacks against links 
> between routers.  GTSM is clever, but fails in the context of such attacks. 
> The existing TCP-MD5 checksum is poor cryptographically, but the bigger 
> problem is the lack of automated key management capability. I think it is 
> reasonable to start by addressing peering session security, on a 
> point-to-point basis, the move on to the harder, transitive security issues 
> associated with advertisements.

I'd like to know if folks have actually asked what the BGP operators 
actually _want_.  Unless I see a survey on this, I will continue to 
believe that less than 5% of operators see an urgent need for new 
mechanisms in the peering session security problem space.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 13:26:05 -0500

At 5:13 PM +0000 1/19/06, Paul Jakma wrote:
>>yes, but vague comments about performance and manageability are 
>>just fodder for debate, not objective metrics that should be 
>>described as "requirements." :-)
>
>Indeed, agreed. Pekka's original comment though did point at a 
>better definition though:
>

I'd suggest text more consistent with a goal flavor, e.g.,

Processing

The introduction of mechanisms to improve routing security will 
generally increase the processing performed by a router. The 
increased processing typically will result from additional checks 
performed to determine the validity of UPDATEs, especially if these 
checks entail cryptographic operations. Since currently deployed 
routers generally do not have hardware to accelerate cryptographic 
operations, these operations could impose a significant processing 
burden under some circumstances. Thus proposed solutions should be 
evaluated carefully with regard to the processing burden they may 
impose, since deployment may be impeded if network operators perceive 
that a specific solution will impose an unacceptable processing 
burden.

This text has the flavor of articulating a goal for solutions, and 
providing a rationale for that goal, but is not worded as a 
requirement.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 13:23:01 -0500

At 7:30 PM +0200 1/19/06, Pekka Savola wrote:
>>session is reset and one receives a lot of UPDATEs from a peer, it 
>>is not necessary to verify the signatures on all of them, if one 
>>uses a mechanism based on signed UPDATEs. One shoud look at each 
>>UPDATE and ask "if this UPDATE is authentic, does it cause me to 
>>change my LocRIB?" If the answer is no, then there is no need to 
>>peform crypto verification on the UPDATE at that time.
>
>I'd say that in most cases the answer would be "yes".  The whole 
>point of peering (unless the link is acting as a cold backup) is to 
>accept prefixes.  Operators also tend to set preferences in the 
>incoming advertisements, making them preferable.

I'm puzzled by this statement. Of course one peers with neighbor ASes 
to accept advertisements. But, not every advertisement will yield a 
better route than the current best route. Flapping is precisely a 
situation where a route oscillates because a sequence of 
advertisements causes this behavior.  But we all want to avoid 
flapping, and try to achieve this via various means, e.g., through 
dampening, preference settings, etc.

I used to assume that the worst case arose when a BGP router was at 
an exchange, with a lot of peers, and thus a lot of opportunities for 
UPDATEs to arrive quickly from  each peer. However, I have been told 
by operators that this is not as bad as I had imagined. The reasoning 
is that the peers at an exchange are mostly downstream providers from 
whom the set of acceptable prefixes is fairly small and static and 
thus filtering (w/o use of crypto checks) would deal with most of 
these UPDATEs.

>needed" prefixes) flap, the resulting computation could be rather 

Again, you refer to the number of prefixes involved, but the cost is 
more properly a function of the number of peers and the length of the 
paths in the advertisements, not the number of prefixes.

>it's productive to continue this discussion in this thread.

Do you think the discussion will become easier or more productive if 
we put this type of language into the document? :-)

>few words on whether that kind of dependency is acceptable or not.

that's a reasonable suggestion.

>>already provides. IPsec allows you to filter ICMP error messages, 
>>to make sure that they come from a source consistent with the 
>>claimed address to which they refer in the payload.
>
>Could you quote the specific text in RFC 4301 Section 6 that 
>specifies this?  I can't seem to find it.

see the cites below.

>...
>ICMP error messages must be accepted from anywhere, with any source address.

not in an IPsec protected environment. remember, IPsec is all about 
access control. we note that ICMP error messages arriving on the 
unprotected side of the boundary cannot generally be authenticated, 
and thus implementations MUST allow an admin to configure controls to 
reject this traffic, and to impose limits on the effects of messages, 
e.g., not allowing the PMTU to be set too low.

>  While the only ICMP error messages relevant to such a BGP TCP 
>session would need to come from your peer, you'd need to have 

Start of 6.2:

When an ICMP error message is transmitted via an SA to a device 
"behind" an IPsec implementation, both the payload and the header of
the ICMP message require checking from an access control perspective. ...

Thus, an IPsec implementation MUST be configurable to check that this 
payload header information is consistent with the SA via which it 
arrives. (This means that the payload header, with source and 
destination address and port fields reversed, matches the traffic 
selectors for the SA.)

This says that when an ICMP error message arrives on an SA from a 
peer, you look at the IP header carried within the message to verify 
that it refers to traffic that would have been carried on the 
matching, outbound SA. Thus, for example, a peer can send ICMP error 
messages that will be accepted ONLY if they refer to traffic that 
would have been sent to that peer.

>mechanisms in the peering session security problem space.

At workshops on routing security conducted by DHS, the range of 
responses was pretty varied. Some operators said that they mandated 
use of the TCP MD5 facility for all their downstream peers, others 
said they refused to use it because of DoS concerns. I don't think 
there is consensus on this topic in the operator community.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 13:39:41 -0500

> Requirements need to be objectively testable to be useful. So, "easy to 
> define" is not show stopper, but impossible to define in an objective, 
> testable fashion is.
> 
> objectively testable, and not simultaneously silly. So, for example, a 
> simple statement like "Any security mechanism MUST/SHOULD NOT degrade 
> router performance" is objectively testable, but its also silly; years 
> of experience indicate that the introduction of any just about security 
> mechanism in any computing or communication environment will add some 
> overhead.

So, then, what you want to be able to say is something more specific. 
For instance, "a pair of BGP speakers MUST be able to exchange and 
install routes no slower than twice the rate at which those speakers 
would exchange and install routes without the security mechanism 
installed with no additional hardware installed (additional off box 
hardware is allowed)...." Or some such, insert what amount of slower 
convergence operators are willing to live with here.

You could get to the point of being so specific as to be unproductive 
with this sort of thing, as well, for two reasons:

- -- It's unproductive to standardize a test on which a standard will 
built; everyone will argue over the test, rather than the actual 
mechanism being designed (witness the current nonsense in the OSPF MANET 
work, where the focus is on the results of simulation, rather than 
actual protocol design).

- -- Everyone will build their system "to the test," defeating the purpose 
of the test in the first place ("Vendor X beats vendor Y in our in house 
forwarding tests")

> consistent with this abstract model, irrespective of how the functions 
> are implemented.
> 
> However you implement BGP, there still needs to be a distinction between 
> an advertisement from a peer that is NOT the best route for a given set 
> of NLRI at the time the advertisement is received, but which still needs 
> to be maintained in case the current best route is withdrawn. One also 
> needs to mark each route based on which peer advertised it, to ensure 
> than only the peer that advertised the route can withdraw it. Given 
> these requirements, it is still possible to do what I described, i.e., 
> don't spend time validating a route which does not appear to be the best 
> route for a given set of NLRI.

Perhaps, perhaps not, in all conditions. We're digging into the 
efficiency of a particular proposed solution, however, which really 
isn't necessarily good territory to get into, here.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 13:54:01 -0500

> I'm puzzled by this statement. Of course one peers with neighbor ASes to 
> accept advertisements. But, not every advertisement will yield a better 
> route than the current best route. Flapping is precisely a situation 
> where a route oscillates because a sequence of advertisements causes 
> this behavior.  But we all want to avoid flapping, and try to achieve 
> this via various means, e.g., through dampening, preference settings, etc.
> 
> I used to assume that the worst case arose when a BGP router was at an 
> exchange, with a lot of peers, and thus a lot of opportunities for 
> UPDATEs to arrive quickly from  each peer. However, I have been told by 
> operators that this is not as bad as I had imagined. The reasoning is 
> that the peers at an exchange are mostly downstream providers from whom 
> the set of acceptable prefixes is fairly small and static and thus 
> filtering (w/o use of crypto checks) would deal with most of these UPDATEs.

Again, this is directed at the efficiency of a specific proposed 
mechanism, which really isn't a good direction to be taking on this 
list, but I'll try to answer this to some degree or another.

This assumes two things about BGP implementations that aren't true, the 
first of which is good for this specific proposed solution, the second 
of which is very bad. In a real startup mode, no BGP implementations 
actually process routes as they are received. They store routes, and 
wait until all their peers are finished talking, then process routes, 
and then send what their best paths are.

The bad thing is that you aren't likely to receive the route you're 
going to end up preferring in the first set of routes you receive. 
Statistically, the route you're going to end up preferring will probably 
come about half way through the advertisements you're receiving. In the 
startup case, this probably doesn't matter. In other cases, where you 
lose a large number of peers, but not all of them, it can matter a great 
deal.

I would point out that we can't assume, from the beginning, that all 
routing information is going to wind up as "completely trustable" or 
"completely garbage." I think that's been an assumption throughout, but 
it's obviously not true, when you consider incremental deployments. For 
instance, suppose you have two routes, one of which you can "validate," 
in some way, three of the AS' in the AS Path. In the other route, you 
can "validate" only two of the AS' in the AS Path.

Is it reasonable to expect the provider to be able to choose between 
these two routes, based on the degree to which the AS Paths can be 
validated, in some way? Or should the security system require that both 
routes be treated equally, since some part of the AS Path can be 
"validated?" If the first is true, then this concept of "I'll find my 
best path, and then validate it just before I install it," falls apart, 
in many circumstances. How well a route can be "validated" becomes a 
part of the decision process itself.

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 14:30:09 -0500

Russ,

>convergence operators are willing to live with here.

you could do that in an effort to satisfy the objective testability 
criteria I mentioned, but we probably would not get consensus on the 
parameters.

>work, where the focus is on the results of simulation, rather than

we're not talking about a standard test, but rather requirements that 
are testable. most IETF standards do not address performance 
explicitly, and I think we are seeing the problems that can arise 
when we try to make performance metrics requirements.

>of the test in the first place ("Vendor X beats vendor Y in our in house

I think this would be a more serious concern if we were talking about 
test cases, vs. performance metrics, but I agree that this is a 
possible trap.

>isn't necessarily good territory to get into, here.

I'm happy to avoid detailed discussions of specific proposals, so 
long as other don't head down that path.  But, if we try to make 
performance criteria into requirements we may be drawn into that 
arena.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 14:51:05 -0500

Russ,

>list, but I'll try to answer this to some degree or another.

Actually my analysis is applicable to ANY solution that expends 
resources to validate a received UPDATE. It is more important if the 
UPDATE validation processing  might be resource intensive, but it 
applicable in any case.

>and then send what their best paths are.

your characterization seems a bit incomplete, in that it does not say 
how a router tells when a peer has no more UPDATEs to send, e.g., a 
timer. also, my analysis was not limited to startup mode.

>lose a large number of peers, but not all of them, it can matter a great

I do not understand the argument above. If, upon startup, a router 
waits for all (active) peers to  "finish talking", as you said, then 
at the end of that interval there is exactly one route that is the 
best route for each prefix, right? Only UPDATEs that arrive later, 
after the end of the "finished talking" interval, could offer routes 
that are new and potentially better that the current best route. So, 
where does 50% enter into this calculation?

>can "validate" only two of the AS' in the AS Path.

I've not made the assumption you cited. Your text, however, includes 
an assumption that a portion of a route may be amenable to 
validation. Incremental deployment may or may not yield such 
situations, depending on the mechanism in question.

>part of the decision process itself.

In general, in configuring security mechanisms, people have found 
that management complexity can easily overwhelm the intended security 
benefits of the mechanisms. Thus we have to be careful to not expect 
operators to accurately configure potentially complex validation 
parameters in order to take advantage of the info that may be 
available due to partial deployment of a routing security mechanism, 
dealing with routes that are not merely valid or unknown.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 15:22:15 -0500

>> This assumes two things about BGP implementations that aren't true,
>> the first of which is good for this specific proposed solution, the
>> second of which is very bad. In a real startup mode, no BGP
>> implementations actually process routes as they are received. They
>> store routes, and wait until all their peers are finished talking,
>> then process routes, and then send what their best paths are.

>  how a router tells when a peer has no more UPDATEs to send, e.g., a
Correct. I wasn't trying for a tutorial on how BGP is implemented, just
giving a general overview. :-)

>>  Statistically, the route you're going to end up preferring will
>> probably come about half way through the advertisements you're
>> receiving. In the startup case, this probably doesn't matter. In
>> other cases, where you lose a large number of peers, but not all of
>> them, it can matter a great deal.
> 

To repeat:

>> In other cases, where you lose a large number of peers, but not all
>> of them, it can matter a great deal.

>> I would point out that we can't assume, from the beginning, that
>> all routing information is going to wind up as "completely
>> trustable" or "completely garbage." I think that's been an
>> assumption throughout, but it's obviously not true, when you
>> consider incremental deployments. For instance, suppose you have
>> two routes, one of which you can "validate," in some way, three of
>> the AS' in the AS Path. In the other route, you can "validate" only
>> two of the AS' in the AS Path.
> 

First, I believe all currently proposed solutions can have this 
property. Second, I think it would actually be hard to design a system 
that doesn't have this property, unless the system arbitrarily places 
this type of partial validation out of bounds for some reason.

>> Is it reasonable to expect the provider to be able to choose
>> between these two routes, based on the degree to which the AS Paths
>> can be validated, in some way? Or should the security system
>> require that both routes be treated equally, since some part of the
>> AS Path can be "validated?" If the first is true, then this concept
>> of "I'll find my best path, and then validate it just before I
>> install it," falls apart, in many circumstances. How well a route
>> can be "validated" becomes a part of the decision process itself.
> 

Parameters are different from policy. Providers today deal with much 
more complex policy than this--and I wouldn't preclude the use of 
possibly policies just because the designer of the system thinks the 
users of that system will find them "too complicated."

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 15:28:47 -0500

> criteria I mentioned, but we probably would not get consensus on the 

I believe you could, actually, reach concensus on a very loosely worded 
test of this type. You must be careful not to jump too far down into 
details, but it might be a useful excercise to see if we can build 
wording that is "crisper" to make those unhappy about the "looseness" of 
the current wording happy, while at the same time leaving the concept 
open enough to interpretation to make a range of tests under a range of 
conditions useful.

I would prefer to examine the performance impacts by examining the real 
world impacts of any given solution on actual implementations, but 
that's a completely different measure, and is harder to quantify.

:-)

Russ

- --

---

From: Tony Li <[email-masked]>
Date: Thu, 19 Jan 2006 13:17:33 -0800

Steve,

> between an advertisement from a peer that is NOT the best route for  
> a given set of NLRI at the time the advertisement is received, but  
> which still needs to be maintained in case the current best route  
> is withdrawn. One also needs to mark each route based on which peer  
> advertised it, to ensure than only the peer that advertised the  
> route can withdraw it. Given these requirements, it is still  
> possible to do what I described, i.e., don't spend time validating  
> a route which does not appear to be the best route for a given set  
> of NLRI.

That may be possible, but it is unlikely to be the best  
implementation approach.  Any path that is
accepted by the system may, at some point in the future, become the  
best path.  An
implementation COULD choose to defer validation until a path is  
selected, but this would
cause computational load to be transferred to a convergence event,  
thus impacting overall
convergence times.  Thus, a more sophisticated approach is to attempt  
to validate all
authenticated paths, but to do so with background processing.  IMHO,  
this is an
architectural requirement for any tractable and deployable solution:  
it must be possible to
temporally decouple security processing from the remainder of BGP  
processing so that
the security overhead can be shifted out of the convergence window.

Regards,
Tony

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 15:38:02 -0500

Russ,

>giving a general overview. :-)

and the answer to my question is ...?

>  >> of them, it can matter a great deal.

that's not an answer to my question

>this type of partial validation out of bounds for some reason.

S-BGP can be incrementally deployed, but we made a decision long ago 
to NOT try to provide partial path validation, for two good (not 
arbitrary) reasons:

	- to take advantage of partial path validation the configuration
	  of routers would be very complex
	- since a side effect of adding signatures to UPDATEs is consumption
	  of more memory in the RIB(s), it seemed likely that ASes that did
	  not deploy the technology would not have enough memory to hold
	  the signatures for which they had no use

>users of that system will find them "too complicated."

Policies are human expressions of criteria, that have to be 
translated into machine-interpretable language for enforcement by 
machines. Parameters are often the means by which such language is 
represented, e.g., ACLs, firewall filter rules, etc. The 1998 NRC 
report "Trust in Cyberspace" notes that many computer and network 
security problems that we experience are attributable to an inability 
by administrators (and users) to manage security controls for complex 
environments. I think what we are discussing here is a perfect 
example of that.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 17:19:34 -0500

At 1:17 PM -0800 1/19/06, Tony Li wrote:
>accepted by the system may, at some point in the future, become the best path.

agreed

>   An
>convergence times.

maybe, depends on how fast the validation is. it might be the case 
that trying to validate all advertisements would overwhelm the router 
during busy times, but that validation of just the viable candidate 
"best" routes would avoid this problem. I bet one needs a fairly 
accurate simulation to tell.

>Thus, a more sophisticated approach is to attempt to validate all
>authenticated paths, but to do so with background processing.

background processing might be a good solution in general, but in the 
situations where the processing load is most likely to be a concern, 
it may be that there is not enough "background" time available for 
such processing.

>   IMHO, this is an

This is certainly an implementation issue; it may or may not be an 
architectural issue. Most descriptions of routing security mechanisms 
I've seen would accommodate any of the approaches we have discussed, 
i.e., do it now, do it when you have to, or do it in the background.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 17:20:38 -0500

> and the answer to my question is ...?

Depends on the implementation. :-) Generally timers started at specific 
places in the peering relationship paired with a set of timers.

> Policies are human expressions of criteria, that have to be translated 
> into machine-interpretable language for enforcement by machines. 
> Parameters are often the means by which such language is represented, 
> e.g., ACLs, firewall filter rules, etc. The 1998 NRC report "Trust in 
> Cyberspace" notes that many computer and network security problems that 
> we experience are attributable to an inability by administrators (and 
> users) to manage security controls for complex environments. I think 
> what we are discussing here is a perfect example of that.

Policies are local, and determine preference, while options are global 
(or at least end-to-end at each peering session), and determine 
operational sequence and properties, etc. I see these as two completely 
different fields.

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 18:00:16 -0500

Russ,

>operational sequence and properties, etc. I see these as two completely

"options?" when did options enter the discussion?

Steve

---

From: Paul Jakma <[email-masked]>
Date: Thu, 19 Jan 2006 23:49:23 +0000 (GMT)

> impose, since deployment may be impeded if network operators 
> perceive that a specific solution will impose an unacceptable 
> processing burden.

That works for me.

> providing a rationale for that goal, but is not worded as a 

Right, it's more a recommendation.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Plan to throw one away.  You will anyway."
- Fred Brooks, "The Mythical Man Month"

---

From: Tony Li <[email-masked]>
Date: Thu, 19 Jan 2006 15:57:11 -0800

Steve,

> maybe, depends on how fast the validation is.

I think it's reasonably safe to assume that any validation operation  
will take non-zero time
and computational resource.  Even if there is a way to offload this  
to another processor, there
is some overhead (e.g., a DMA setup).

> background processing might be a good solution in general, but in  
> the situations where the processing load is most likely to be a  
> concern, it may be that there is not enough "background" time  
> available for such processing.

Agreed, in which case it would impact convergence.  Again, the  
sophisticated implementation
can prioritize the validation of best prefixes to the foreground,  
while moving alternate prefixes
to the background.

An implementation may also choose to simply select and utilize  
alternate paths BEFORE validation.  This is not unreasonable under  
the assumption that all paths will eventually be
validated or they will set of alarms elsewhere in the network and  
that temporarily broken
connectivity while under attack is better that very slow convergence  
always.

>>   IMHO, this is an
>> architectural requirement for any tractable and deployable  
>> solution: it must be possible to
> architectural issue. Most descriptions of routing security  
> mechanisms I've seen would accommodate any of the approaches we  
> have discussed, i.e., do it now, do it when you have to, or do it  
> in the background.

I think that anyone wishing to have a proposal that passes the laugh  
test and actually gets
implementation resources devoted to it had best keep this in mind.  I  
won't argue with you
about whether it's architectural or an implementation issue.  It is a  
pragmatic requirement
of any deployable solution and it does not seem to be recognized as  
such, as far as I can
tell.  I do believe that it places significant constraints on the  
solution space and thus
does have some significant bearing on the situation.

Tony

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 20:06:01 -0500

>> generally increase the processing performed by a router. The increased 
>> processing typically will result from additional checks performed to 
>> determine the validity of UPDATEs, especially if these checks entail 
>> cryptographic operations. Since currently deployed routers generally 
>> do not have hardware to accelerate cryptographic operations, these 
>> operations could impose a significant processing burden under some 
>> circumstances. Thus proposed solutions should be evaluated carefully 
>> with regard to the processing burden they may impose, since deployment 
>> may be impeded if network operators perceive that a specific solution 
>> will impose an unacceptable processing burden.

> That works for me.

I believe this is too "soft," simply saying you should examine this 
issue, not what the result should be. Perhaps replace the last sentence 
with:

"Thus proposed solutions should be evaluated with regard to the 
processing burden they impose. Solutions with lower processing burdens, 
and solutions capable of allowing processing to take place on devices 
outside the router, SHOULD be preferred."

I think that more of right sense. It doesn't specify how to evaluate 
these things, it gives hints as to what to look for, and it gives mild 
direction as to how to handle the results of any given evaluation.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 20:09:42 -0500

> "options?" when did options enter the discussion?

What would you prefer to call the various capabilities a protocol can 
use to modify its operation? My point is there's a radical difference 
between having ten different ways to encapsulate data, five different 
key options, four different signalling mechanisms, etc, and the ability 
to locally configure policy to prefer one route over another, based on 
security, as well as other parameters.

I, for one, do not want to see a mechanism standardized that only 
provides "valid" or "invalid" as its output. This is not a piece of data 
you're transporting across a network that's either correct or incorrect, 
like an encrypted email.

:-)

Russ

- --

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 20 Jan 2006 10:41:50 +0100

----- Original Message ----- 
From: "Stephen Kent" <[email-masked]>
To: "Tony Tauber" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 11, 2006 4:32 PM
Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03

> Tony,
<snip>
> the current BGP spec (in the RFC editor's queue) ...

Now an RFC, in fact about ten of them, starting at RFC 1771+2500=4271.

Tom Petch

> does not relax the

---

From: Pekka Savola <[email-masked]>
Date: Fri, 20 Jan 2006 14:24:19 +0200 (EET)

...
>> I'd say that in most cases the answer would be "yes".  The whole point of 
>> peering (unless the link is acting as a cold backup) is to accept prefixes. 
>> Operators also tend to set preferences in the incoming advertisements, 
>> making them preferable.
>
> accept advertisements. But, not every advertisement will yield a better route 
> than the current best route. Flapping is precisely a situation where a route 
> oscillates because a sequence of advertisements causes this behavior.  But we 
> all want to avoid flapping, and try to achieve this via various means, e.g., 
> through dampening, preference settings, etc.

In my experience, the current mechanisms are not flexible enough and 
sufficiently widely used to support this.

Let's take an example: an ISP has two upstream providers, and wants to 
mainly use one of them for whatever reasons.  When that session goes 
down, 200K routes get active on the backup session.  When that session 
comes back up, 200K routes get re-activated on the primary session. 
The same applies to peering with smaller number of prefixes.

> exchange, with a lot of peers, and thus a lot of opportunities for UPDATEs to 
> arrive quickly from  each peer. However, I have been told by operators that 
> this is not as bad as I had imagined. The reasoning is that the peers at an 
> exchange are mostly downstream providers from whom the set of acceptable 
> prefixes is fairly small and static and thus filtering (w/o use of crypto 
> checks) would deal with most of these UPDATEs.

For those operators, less than 20% of peers contribute over 80% of 
prefixes (or so I'd estimate). Yet, the large number of prefixes heard 
from peers (rather than downstreams) is the real problem.

>>  While the only ICMP error messages relevant to such a BGP TCP session 
>> would need to come from your peer, you'd need to have verification checks 
>> in the ICMP processing code that deals with this case when the ICMP error 
>> carries only an IP header and 8 bytes of payload.  At the moment, I haven't 
>> been able to locate this text in RFC 4301.
>
> Start of 6.2:
>
> When an ICMP error message is transmitted via an SA to a device "behind" an 
> IPsec implementation, both the payload and the header of

This text deals with ICMPs protected by an SA.  Do you assume that 
ICMP traffic between the neighbors would need to be protected by an 
SA?

> Thus, an IPsec implementation MUST be configurable to check that this payload 
> header information is consistent with the SA via which it arrives. (This 
> means that the payload header, with source and destination address and port 
> fields reversed, matches the traffic selectors for the SA.)
>
> This says that when an ICMP error message arrives on an SA from a peer, you 
> look at the IP header carried within the message to verify that it refers to 
> traffic that would have been carried on the matching, outbound SA. Thus, for 
> example, a peer can send ICMP error messages that will be accepted ONLY if 
> they refer to traffic that would have been sent to that peer.

AFAICS, this doesn't really help:
  - source and destination addresses from the IP header can be checked 
but are not integrity-protected
  - the payload need not include more than 8 bytes of the payload, so 
in case of ESP (for example, similar for AH), you could only see the 
IPsec SPI and Acknowledgement number.

Maybe you're assuming that the peer would send back the whole packet 
in ICMP payload (so that you could pass it to the IPsec layer for 
cryptographic verification).  That's not required by RFC 1812.

As the integrity of the payload cannot be verified, I think anyone can 
send an ICMP message which contains the source and destination address 
used by the outbound SA.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Jan 2006 10:13:53 -0500

Tony,

Upon reading your responses I think we are generally in agreement. 
Any route validation process will require some processing, thus will 
contribute in some way to delays in transmitting a new UPDATE, and 
thus may impact convergence time.  However, without an implementation 
and realistic testing, or very detailed analysis and simulation, it 
probably is not possible to determine the extent to which convergence 
is affected by a given mechanism, at least in many cases. Since there 
already seems to be considerable variance in convergence times based 
on other aspects of specific BGP implementation and the parameter 
setting for an implementation, it would seem premature to declare 
that every deferred processing approach will be unacceptable, or that 
background processing will always be preferable.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Jan 2006 10:08:18 -0500

Russ,

>direction as to how to handle the results of any given evaluation.

The problem with your wording is that a solution with a lower 
processing burden is automatically preferred. However, the lower 
burden might be only slightly lower, and thus of little practical 
import. If a slightly more burdensome solution offered much better 
security, it would seem inappropriate to automatically prefer the 
less burdensome solution, with worse security.  So, that's why I 
suggest we describe why performance is a concern and thus why it 
needs to be considered in evaluating solutions, but why we ought not 
try to create a requirement based on performance.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Jan 2006 10:43:38 -0500

Russ,

>security, as well as other parameters.

I no longer have any idea what you're talking about relative to our 
original discussion, so I'll just stop pursuing attempts to clarify 
these comments.

>you're transporting across a network that's either correct or incorrect,

At lower levels, security mechanisms do output precisely 
valid/invalid indications. This is true for integrity checks, 
authentication checks, and authorization checks, and has been for 
decades. One can choose to takes these outputs from security 
mechanisms and allow a person to make a value judgement that 
determines how the output affects behavior. One can try to translate 
the human decision criteria into a machine-enforceable policy. 
However, we often see people unable to interpret the binary outputs 
of the low level mechanisms. We almost always see people surprised by 
the results of trying to translate their decisions processes into 
machine-enforceable policies.

Using the e-mail example above, S/MIME will tell a user if a message 
is signed or not, if the signature can be validated using available 
trust anchors and cert status data, and whether the result of the 
validation procedure was successful.  All of these are binary outputs 
but users have trouble dealing wit them, in practice. For example, 
S/MIME software generally will not pop up a window to display the 
cert that was validated, for a signed message. Thus a user will tend 
to think that the name in the From field has been verified as the 
sender of the message, but that is not what was checked! Also, even 
in an environment where signed e-mail is common (or nominally 
required) a user will not automatically reject all unsigned messages.

My concern is that if we give network operators a complex set of 
controls for dealing with security characteristics for 
advertisements, the result will be way too hard for many (most?) 
operators to use safely. A simple output of verified or not verified 
is probably OK, but any sort of partial verification (3 out of 5 ASes 
in the path?) is likely to cause more confusion that its worth.  I 
don't say this because I know how operators work; I say it because I 
have a lot of experience with security management technologies. My 
view on this topic is shared by others in the security arena, as 
noted in the NRC report I cited in a previous message.

Steve

---

From: Russ White <[email-masked]>
Date: Fri, 20 Jan 2006 11:07:53 -0500

> try to create a requirement based on performance.

That's why it's a SHOULD rather than MUST--these are things that need to 
be traded off against other requirements in the draft.

Saying: "You must consider the processing burdens" gives no guidance 
whatsoever. The simple answer is: "I've considered it, and I believe it 
doesn't matter." That's a valid answer, based on the text you've 
suggested--but it's not a valid answer given the intent of the text.

Another possibility is:

Thus proposed solutions should be evaluated with regard to the
processing burden they impose. Gains in security MUST be weighted 
against increases in processing burden, including the ability to shift 
processing requirements onto devices external to an implementing router. 
Solutions imposing smaller processing burdens with small perceived 
operational security losses SHOULD be preferred.

BTW, weren't you just arguing for more precise language, rather than 
less precise language? :-)

:-)

Russ

- --

---

From: Pierre Baume <[email-masked]>
Date: Fri, 20 Jan 2006 17:20:20 +0100 (CET)

Tony,

On Thu, 19 Jan 2006, Tony Li wrote:
[...]

> Again, the sophisticated implementation can prioritize the validation of
> best prefixes to the foreground, while moving alternate prefixes to the
> background.
>
> An implementation may also choose to simply select and utilize alternate
> paths BEFORE validation.  This is not unreasonable under the assumption
> that all paths will eventually be validated or they will set of alarms
> elsewhere in the network and that temporarily broken connectivity while
> under attack is better that very slow convergence always.
[...]

> Tony

  The text above might have been for the sake of the argument, but I'd
expect that validated (though possibly stale) prefixes should always be
preferred to unvalidated ones.

  In the first scenario above, the injection of many illegitimate,
seemingly good prefixes, would delay, possibly forever, depending on the
prioritisation, the validation of legitimate, less good prefixes.

  In the second one, it's worse, these illegitimate, seemingly good
prefixes would be used, instead of the previously known good prefix (which
might still be the best).

  I'd argue for first come, first validated and not validated, not used.

Pierre.

---

From: Russ White <[email-masked]>
Date: Fri, 20 Jan 2006 11:24:43 -0500

> At lower levels, security mechanisms do output precisely valid/invalid 
> indications. This is true for integrity checks, authentication checks, 
> and authorization checks, and has been for decades. One can choose to 
> takes these outputs from security mechanisms and allow a person to make 
> a value judgement that determines how the output affects behavior. One 
> can try to translate the human decision criteria into a 
> machine-enforceable policy. However, we often see people unable to 
> interpret the binary outputs of the low level mechanisms. We almost 
> always see people surprised by the results of trying to translate their 
> decisions processes into machine-enforceable policies.
> 
> Using the e-mail example above, S/MIME will tell a user if a message is 
> signed or not, if the signature can be validated using available trust 
> anchors and cert status data, and whether the result of the validation 
> procedure was successful.  All of these are binary outputs but users 
> have trouble dealing wit them, in practice. For example, S/MIME software 
> generally will not pop up a window to display the cert that was 
> validated, for a signed message. Thus a user will tend to think that the 
> name in the From field has been verified as the sender of the message, 
> but that is not what was checked! Also, even in an environment where 
> signed e-mail is common (or nominally required) a user will not 
> automatically reject all unsigned messages.

The problem is that an email is all "one thing." Let's extend the 
example a little, and it might make more sense.

Suppose you receive 10 emails, all with signatures, and all with 
slightly different attachments. Now, all of them pass through your 
signature test, but you can actually only read one of them. Which one 
will you pick? Now, suppose you could set up a local policy about which 
one to pick--would you simply say: "Well, they all pass the signature 
test, so they're all equal there?"

Or, would you be inclined to say: "Well, these four also have their 
attachments signed, and these six don't, so let's toss out the six that 
don't, since I know I can trust those attachments?"

I believe you would choose the latter. The problem is, you're injecting 
a false sense of the "oneness" of a BGP "route" into the system that 
doesn't exist in real BGP, or real BGP implementations.

As for the assertion that providers aren't going to "be able to handle 
the policy, it's too complex," I would say that you shouldn't be so sure 
of that. If I were a provider, I would say: "The more policy control you 
can give me, the better, no matter if you think I can handle it or not."

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Jan 2006 11:28:34 -0500

Russ,

>be traded off against other requirements in the draft.

Saying SHOULD vs. MUST does not adequately convey the tradeoff notion 
that you suggest. It establishes performance as a more important 
criteria than security, but that's all it says.

>suggested--but it's not a valid answer given the intent of the text.

But it IS a valid answer if the example I gave were being considered, 
e.g., the performance different is so small between the two 
candidates that the difference doesn't matter, or it's small and the 
security benefits of one outweigh the performance benefits of the 
other.

>less precise language? :-)

I argued that IF you insist on making the text a requirement, then it 
needs to be more precise. If it is a goal statement, as I suggest, 
then precision is not needed. I belive this is still the case, which 
is why I am not enthusiastic about the revised wording.

Steve

---

From: Russ White <[email-masked]>
Date: Fri, 20 Jan 2006 12:02:34 -0500

> criteria than security, but that's all it says.

Actually, I disagree with this. There are specific things, in security 
terms, any proposed ssytem MUST do to be considered, and there are some 
things that any proposed system SHOULD do to be considered. The SHOULD 
language in my proposed text simply allows the designers to trade off 
between the various SHOULDs contained in the document.

The way you would word it processing burdens would not be considered at all.

> e.g., the performance different is so small between the two candidates 
> that the difference doesn't matter, or it's small and the security 
> benefits of one outweigh the performance benefits of the other.

Now you're making all sorts of value judgements without precise language 
stating what you should do with those value judgements, and no way of 
measuring those value judgements. In effect, taking the SHOULD out 
strips this text of actually saying anything useful.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Fri, 20 Jan 2006 12:07:38 -0500

> prioritisation, the validation of legitimate, less good prefixes.

Aren't "more good" and "less good" policy concerns best left to the 
provider? In other words, BGP traditionally gives users a set of tools, 
and leaves it up to them as to how to use those tools, beyond simply 
taking out routes that are provably loops.

This is part of the difference between the routing world and the 
security world; things in the security world are very black and white. 
Either it's valid, or it's invalid. You don't adjust preferences, you 
either trust something, or throw it away. BGP has a few "black and 
white" decisions, and a lot of "preference" decisions.

:-)

Russ

- --

---

From: Paul Jakma <[email-masked]>
Date: Fri, 20 Jan 2006 17:43:36 +0000 (GMT)

On Fri, 20 Jan 2006, Stephen Kent wrote:

> needs to be considered in evaluating solutions, but why we ought 
> not try to create a requirement based on performance.

Ack, balance between the two is what is desired. A no-brainer 
obviously.

The problem, again obviously, is where that balance should lie. If 
it's not within the remit of this group to decide on that issue, then 
Stephen's text is perfect imho.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You know you've landed gear-up when it takes full power to taxi.

---

From: Russ White <[email-masked]>
Date: Fri, 20 Jan 2006 13:43:51 -0500

>> suggest we describe why performance is a concern and thus why it needs 
>> to be considered in evaluating solutions, but why we ought not try to 
>> create a requirement based on performance.
> 
> Ack, balance between the two is what is desired. A no-brainer obviously.
> 
> The problem, again obviously, is where that balance should lie. If it's 
> not within the remit of this group to decide on that issue, then 

I believe it is "within the remit of this group" to provide guidance on 
where that balance should lie. Choosing "security required, 
deployability optional" isn't a balance.

Again, if there's no guidance to be given, then we are ignoring the 
operator's input (which has been the direction this process has been 
pushed anyway, looking at the history of it), and I disagree with that 
completely.

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Jan 2006 15:05:47 -0500

>don't, since I know I can trust those attachments?"

bad analogy, in more than one way.  An ability to sign the message 
body also confers an ability to sign attachments. So, did you mean 
that some messages have no attachments and thus no signed 
attachments, or that some have attachments that are not signed even 
though the message is signed?  See how even a little complexity, 
coupled with imprecise attempts to express a policy leads to 
confusion?

>doesn't exist in real BGP, or real BGP implementations.

huh?

>can give me, the better, no matter if you think I can handle it or not."

A very manly statement, but experience suggests that more knobs leads 
not to greater security through more fine-grained control, but to 
more config errors :-).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Jan 2006 15:41:07 -0500

At 12:02 PM -0500 1/20/06, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>

MUST and SHOULD are reserved words in the context of Internet 
standards track documents. Using them to express preferences in 
tradeoffs is not within the scope of their definition as per RFC 2119.

>The way you would word it processing burdens would not be considered at all.

I don't think most individuals who are proficient in English would 
agree with that characterization.

>strips this text of actually saying anything useful.

I'm giving an example that demonstrates why your proposed wording is biased.

>  >> operational security losses SHOULD be preferred.

I do have a problem  with it.

Russ, irrespective of your technical capabilities in the routing 
area, our extended debates on this list often have shown that you 
often have trouble generating language that is clearly understood by 
all WG members.  Perhaps we need to have someone else work on 
suitable language here.

Steve

---

From: Russ White <[email-masked]>
Date: Fri, 20 Jan 2006 16:50:32 -0500

> bad analogy, in more than one way.  An ability to sign the message body 
> also confers an ability to sign attachments. So, did you mean that some 

Bad assumption.... :-)

> messages have no attachments and thus no signed attachments, or that 
> some have attachments that are not signed even though the message is 
> signed?  See how even a little complexity, coupled with imprecise 
> attempts to express a policy leads to confusion?

Certainly, but as a receiver, I should be able to handle problems like 
this, rather than simply saying: "I declare all received messages 
invalid that aren't completely signed." In fact, this sort of 
decleration makes partial deployments of a routing security system 
impossible, since it's impossible to believe that the entire AS Path is 
going to be validatable (??) on day one, or even at _any_ point in the 
future realm of possibility.

> not to greater security through more fine-grained control, but to more 
> config errors :-).

Perhaps, perhaps not.

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Jan 2006 13:47:46 -0500

Pekka,

>sufficiently widely used to support this.

Are you saying that you don't feel that current mechanisms deal well 
with suppression of route flaps? if so I agree that there is a lot of 
room for improvement, which is important irrespective of whether we 
deploy routing security mechanisms.

>Let's take an example: an ISP has two upstream providers, and wants 
>to mainly use one of them for whatever reasons.  When that session 
>goes down, 200K routes get active on the backup session.  When that 
>session comes back up, 200K routes get re-activated on the primary 
>session. The same applies to peering with smaller number of prefixes.

OK, fair example, except that I thought the route total these days 
was about 180K, but, hey, what's 20K routes among friends :-)?

>prefixes (or so I'd estimate). Yet, the large number of prefixes 
>heard from peers (rather than downstreams) is the real problem.

OK. But, as I noted earlier, the number of prefixes is not so much an 
issue as the number of UPDATE messages that carry them, and the 
number of hops for each route.

>ICMP traffic between the neighbors would need to be protected by an 

yes, but that can be one SA that carries both ICMP traffic plus BGP traffic.

>  - source and destination addresses from the IP header can be 
>checked but are not integrity-protected

If there is one SA between two peers, and that SA carries the ICMP 
error messages, then the S/D address check is implicit. This is 
because the key used for that SA is unique to the peers and the S/D 
values are checked as part of the access control processing applied 
to all incoming (IPsec-protected) packets via the SAD entry.

>IPsec SPI and Acknowledgement number.

If the ICMP error message is generated using the IPsec-protected, 
received message then yes, the returned content is limited. But, I 
think it is sufficient anyway.

>cryptographic verification).  That's not required by RFC 1812.

I don't assume more than the usual ICMP error message requirements. 
But I do assume that the ICMP message is IPsec-protected.

>As the integrity of the payload cannot be verified, I think anyone 
>can send an ICMP message which contains the source and destination 
>address used by the outbound SA.

Not quite. If the ICMP message is received via then same SA that 
carries BGP traffic (which is what I have assumed), then the receiver 
knows the source and the IPsec processing for ICMP error messages 
will reject an error message IF the error message purports to refer 
to traffic that would not have been carried on the SA via which it 
was received.

Steve

---

From: Paul Jakma <[email-masked]>
Date: Mon, 23 Jan 2006 22:34:50 +0000 (GMT)

On Fri, 20 Jan 2006, Russ White wrote:

> I believe it is "within the remit of this group" to provide 
> guidance on where that balance should lie. Choosing "security 
> required, deployability optional" isn't a balance.

Agreed.

> operator's input (which has been the direction this process has 
> been pushed anyway, looking at the history of it), and I disagree 
> with that completely.

Well Stephen's proposed text does refer to the deployability balance:

"Thus proposed solutions should be evaluated carefully with regard to 
the processing burden they may impose, since deployment may be 
impeded if network operators perceive that a specific solution will 
impose an unacceptable processing burden."

That seems quite reasonable, balanced and neutral.

More to the point, how long can we go on to argue 'by proxy' via the 
requirements text? Either let's discuss and decide on the points 
festering behind the scenes here directly, or if it's not in scope to 
do so, let's adopt something reasonable that remains neutral and 
hence has some chance of consensus so the next group which /will/ be 
allowed to argue the meat of the matter and make the decision(s) can 
then go and do so.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Remember: use logout to logout.