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

From: "Bora Akyol" <[email-masked]>
Date: Wed, 11 Jan 2006 16:43:11 -0800

I think we need to define what constitutes an unreasonably heavy load
in terms of a load metric (as in queueing theory).

I presume a simple definition of offered load vs goodput may suffice.
If the router BGP processing goodput drops significantly due to added
crypto
load, then this constitutes a "heavy load" IMHO.

As far as built-in crypto in router CPUs, there are already several
chips
on the market from many vendors available, so it is just a matter of
the box builder putting this in the router.

Bora

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Stephen Kent
> Sent: Wednesday, January 11, 2006 3:24 PM
> To: Pekka Savola
> Cc: [email-masked]; Tony Tauber
> Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03
> 
> Pekka,
> 
> >>...
> >
> >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.
> 
> 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?
> 
> >>...
> >
> >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..
> 
> yes, I think this is hard to quantify. by making it a (vague) 
> requirement we create a basis for endless debate :-)
> 
> >
> >>>>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.
> >>
> >>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 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.
> 
> >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.
> 
> 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 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.
> 
> 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.
> 
> >>...
> >
> >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).
> 
> >>...
> >
> >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.
> 
> >...
> >
> >(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.)
> >
> 
> OK.
> 
> Steve
> 
> _______________________________________________
> RPSEC mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rpsec
> 
> 

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

---

From: "Bora Akyol" <[email-masked]>
Date: Mon, 16 Jan 2006 09:55:20 -0800

I think adding a statement such as:

While the network elements transition from software-based cryptographic
processing to hardware-based processing, solutions that
allow offload of security processing to another device may be
preferred.

Bora

> =======
> 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 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.
> =======
>

---

From: [email-masked]
Date: Fri, 20 Jan 2006 10:53:15 -0500 (EST)

>So, rather than doing what can be done, you'd rather set the 
>requirements so they are "perfect," without any consideration for 
>deployability, and then deploy nothing for several years, until the 
>entire infrastructure of the Internet and all connected networks can be 
>replaced? I consider this view a bit unrealistic.

I would prefer to analyze the security requirements and then compare
proposed solutions against the security requirements and the
engineering decisions of performance and scale and deployability.
 
I would prefer not to prohibit certain security solutions from
getting any consideration at all because they would present difficulties
in the current environment.   Environments differ now at different
places and at different special purpose networks and will certainly
differ in the future.

The document already says that any solution must tolerate incremental
deployment.  So bringing up the "entire infrastructure of the Internet"
is only a bugaboo.

>Then we should modify the part that says: "Don't require X of all 
>routers," to: "don't require X of all routers on which the proposed 
solution is running."

Exactly as I said:  "If you really mean the "all" part...."

--Sandy