Subject: [Sidr] a reminder on operator requirements

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Nov 2005 17:52:21 +0200 (EET)

Hi,

Food for thought before the BOF.

Unless the operational requirements are suitably well considered from 
the start, we don't accomplish anything as the solution will not be 
deployed.

So, with my operator hat on, let me provide a couple for starters:

  1) No configuration required: this must not add significant amount of 
config/management on the routers.

  2) No observable impact on processing: the route convergence or 
processing delays must not be observable.

  3) No new hardware on routers: the solution must not require adding 
new hardware (e.g., crypto hardware) on all the routers; it may be 
acceptable to have it on one or two, but no more than that.

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

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

---

From: Geoff Huston <[email-masked]>
Date: Sat, 12 Nov 2005 02:56:07 +1100

A first pass of the minutes of the SIDR BOF can be found at

https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64

(look for SIDR BIF in the Routing Area)

comments & corrections welcome

thanks,

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Sat, 12 Nov 2005 03:14:06 +1100

s/BIF/BOF/

:-)

geoff

---

From: Geoff Huston <[email-masked]>
Date: Sat, 26 Nov 2005 07:46:20 +1100

Hi,

At the SIDR BOF the ADs asked for a draft charter to be prepared by the end 
of November. I realize that time is getting close now, and I've prepared 
the following. I trust it encompasses the considerations mentioned at the 
BOF, and provides a reasonable framework for moving forward on this topic.

Please have a look over it and provide any comments to the list (or 
directly to me if you prefer) and I'll post revisions as appropriate. I'd 
like to get this completed and shipped to the ADs in as final format by the 
_30th November_  so please send me any comments as soon as you can!

many thanks,

       Geoff

===================

DRAFT  (26/11/05)
Secure Inter-Domain Routing (sidr)

Chair(s):
   TBD

Routing Area Director(s):
   Bill Fenner <[email-masked]>
   Alex Zinin <[email-masked]>

Routing Area Advisor:
   TBD

Other Advisors:
   ? Security: TBD
   ? Routing: TBD

Mailing Lists:
   General Discussion: [email-masked]
   To Subscribe: [email-masked]
   In Body: (un)subscribe
   Archive: http://www.ietf.org/mail-archive/web/sidr/index.html

Description of Working Group:

   One of the areas of vulnerability for large scale Internet environments 
lies in the area of inter-domain routing. The basic security questions that 
can be posed regarding routing information is that of the validity of the 
address prefix being advertised, the validity of the originating Autonomous 
System Number, and the existence of an explicit permission from the address 
prefix holder to allow the prefix to be advertised from this origin. A 
related question concerns the level of trust than can be ascribed to 
attributes of a routed object in terms of their authenticity.

   The Routing Protocol Security Group (RPSEC) has been chartered to 
document the security requirements for routing systems, and, in 
particular,  to produce a document on BGP security requirements.

   The scope of work in the SIDR working group is to formulate an 
extensible interdomain routing security architecture that is capable of 
supporting incremental additions to a security framework for interdomain 
routing. As and when interdomain routing security requirements are 
completed within the RPSEC Working Group, these requirements will be 
defined within the SIDR framework as functional components of a secure 
interdomain routing system.

   The scope or work will include the definition of certification objects 
that can be used to support the distribution of authentication information. 
Both strict hierarchical and distributed non-hierarchical trust systems are 
intended to be supported within this framework.

   The scope of work is limited to inter-domain router-to-router protocols 
only for both unicast and multicast systems.

   The SIDR working group is charged with the following tasks:

   - Document an extensible interdomain routing security architecture

   - Document the certification objects to be used by this secure
     routing framework

   - Document specific routing functionality modules with this
     architecture designed to address specific secure routing requirements 
as they are determined by the RPSEC Working Group

Goals and Milestones:

April-06  Submit initial draft on inter-domain routing security
           architecture

May-06    Submit  initial draft on certificate objects to be used
           within this framework

May-06    Submit initial draft on securing origination of routing
           information

Sept-06   Submit routing security architecture for publication as an
           Informational RFC

Nov-06    Submit definition of certificate objectes to be used as a
           Proposed Standard

Dec-06    Submit secure origination mechanism as a Proposed Standard

Jan-06    Evaluate progress, recharter with new goals or shutdown.

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 25 Nov 2005 17:36:26 -0800 (PST)

On Sat, 26 Nov 2005, Geoff Huston wrote:

> of November. I realize that time is getting close now, and I've prepared the 
> following. I trust it encompasses the considerations mentioned at the BOF, 
> and provides a reasonable framework for moving forward on this topic.
>
> Please have a look over it and provide any comments to the list (or directly 
> to me if you prefer) and I'll post revisions as appropriate. I'd like to get 
> this completed and shipped to the ADs in as final format by the _30th 
> November_  so please send me any comments as soon as you can!
>
> many thanks,
>
>      Geoff
>
>
> ===================
>
> DRAFT  (26/11/05)

I guess its close to 50/50 in both routing ad security, but to me it
seems we'd be doing more security then routing, so maybe this should
be under security area or at least as special case have both routing
and security area directors overseeing the effort.

> prefix holder to allow the prefix to be advertised from this origin.

Above is ok (small pick at "this" - maybe replace with "given").
One note is that it is unclear if system will deal only with the very 
first origin ASN's permission to advertise the prefix or would also deal 
with transit/peer relationships (ASN->ASN permission to advertise prefix).

> A 

The above is not clear to me, maybe more specific about what attributes.

> The Routing Protocol Security Group (RPSEC) has been chartered to document 
> the security requirements for routing systems, and, in particular,  to 
> produce a document on BGP security requirements.
>
> The scope of work in the SIDR working group is to formulate an extensible 
> interdomain routing security architecture that is capable of supporting 
> incremental additions to a security framework for interdomain routing. As 
> and when interdomain routing security requirements are completed within the 
> RPSEC Working Group, these requirements will be defined within the SIDR 
> framework as functional components of a secure interdomain routing system.

I'm not sure of above. It seems to make start of the work in SIDR 
dependent upon completion of the work within another WG. While I agree
on it in  principle, what it means to me is that SIDR can not be formed 
until those requirements are ready. When the requirements are ready that 
would mean charter text for SIDR could directly reference requirements 
document rather then to reference that RPSEC would produce the document.

> intended to be supported within this framework.

Both? I think this is too strict in requiring final system that can 
support both at the same time where as this may not be achievable.

How about changing this to something like:
"Both strict hierarchical and distributed non-hierarchical trust systems
  are within scope of work and either one or both (if possible) will be
  supported in the final framework"

>    architecture designed to address specific secure routing requirements as 
> they are determined by the RPSEC Working Group

Is documenting how to exchange the certification objects (and how to
publish them in the first place) fits within one of the above?

> Jan-06    Evaluate progress, recharter with new goals or shutdown.

Typo above - should be "Jan-07".

In general I think above schedule of less then one year is too aggressive -
IETF does not seem to have very many examples of WGs being able to produce
such a substantial work within this short period of time.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Sun, 27 Nov 2005 04:50:54 +1100

Thanks for this response - I'll revise the charter with these comments in mind.

I'd like to make a few clarifying comments in response:

- the work is in the routing area because ultimately it it a routing 
protocol that we are working on. Personally I'm not concerned about this at 
all - I know the security ADs and the security area folk are keenly 
interested in this activity and we will have the benefit of their 
perspectives as we progress. I did leave space in the charter for a 
security advisor to the wg to ensure that we can get specific advice as 
required.

- the transit/peer issues you raise are not in the area of concluded 
(agreed) requirements from the RPSEC WG - as and when they complete their 
requirements the SIDR WG will take on the work.

- the reliance on RPSEC outputs was a fundamental part of the SIDR charter 
according to the RPSEC charter and the SIDR BOF (see the minutes from the 
BOF at IETF-64).The BOF discussed the option you put forward in your 
comments and the general consensus in the room was to encompass in the 
charter the broader set of work and explicitly note that embarking on any 
part of the work was conditional of RPSEC outcomes. I have drafted the 
charter in accordance with that approach.

- the requirement for supporting both strict hierarchical and distributed 
trust models was a clear outcome of the BOF. The assertion was made in a 
number of presentations in the BOF that both forms of trust models are 
degenerate cases of the other. It appears that while the public Internet 
may well benefit for a hierarchy of trust there are other inter-domain 
routing environments that use a distributed trust model. I understood from 
the BOF sessions that there was no desire to 'pick one', but to head in a 
direction that defined a standard technology that could encompass various 
trust models.

- and yes, the schedule is aggressive. On the other hand, RPSEC has done 
all the requirements work, there is a certain amount of impatience in 
getting some progress in the IETF in this area, and I see a number of folk 
who are keen to contribute, so I am confident that it is possible to 
complete the documents in this timeframe.

regards,

      Geoff

At 12:36 PM 26/11/2005, william(at)elan.net wrote:

>>At the SIDR BOF the ADs asked for a draft charter to be prepared by the 
>>end of November. I realize that time is getting close now, and I've 
>>prepared the following. I trust it encompasses the considerations 
>>mentioned at the BOF, and provides a reasonable framework for moving 
>>forward on this topic.
>>
>>like to get this completed and shipped to the ADs in as final format by 
>>the _30th November_  so please send me any comments as soon as you can!
>>
>>many thanks,
>>
>>      Geoff
>>
>>
>>===================
>>
>>DRAFT  (26/11/05)
>>lies in the area of inter-domain routing. The basic security questions 
>>that can be posed regarding routing information is that of the validity 
>>of the address prefix being advertised, the validity of the originating 
>>Autonomous System Number, and the existence of an explicit permission 
>>from the address prefix holder to allow the prefix to be advertised from 
>>this origin.
>
>>A related question concerns the level of trust than can be ascribed to 
>>and when interdomain routing security requirements are completed within 
>>the RPSEC Working Group, these requirements will be defined within the 
>>SIDR framework as functional components of a secure interdomain routing system.
>
>>that can be used to support the distribution of authentication 
>>information. Both strict hierarchical and distributed non-hierarchical 
>>trust systems are intended to be supported within this framework.
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 27 Nov 2005 14:11:07 +0100

language/clarity comments.....

>    One of the areas of vulnerability for large scale Internet
> environments lies in the area of inter-domain routing. The basic security
> questions that can be posed regarding routing information is that of the
> validity of the address prefix being advertised, the validity of the
> originating Autonomous System Number, and the existence of an explicit
> permission from the address prefix holder to allow the prefix to be
> advertised from this origin. A related question concerns the level of
> trust than can be ascribed to attributes of a routed object in terms of
> their authenticity.

I think this section may be detailed... the BASIC question that should be 
asked in routing is "if I believe this information, will the result be what 
I want it to be" - but authenticity of the information is usually a good 
start.... unless others have alternative language to propose, this is OK.

Q: should "a routed object" be "a routing information object" or "an object 
passed in a routing protocol"? To me, "a routed object" is a packet, and 
that doesn't seem to make sense....

> routing.

I got lost in that sentence.... what about:

The scope of work in the SIDR working group is to formulate an extensible 
architecture for an interdomain routing security framework. This framework 
must be capable of supporting incremental additions of new functional 
components, but should at the outset be capable of supporting the security 
functions described <where?>.

> As and when interdomain routing security requirements are

Q: Does the work involve revisiting RFC 3779 AS number/address range certs, 
using these certs, or ignoring these certs and do something completely 
different?

>    The scope of work is limited to inter-domain router-to-router
> protocols only for both unicast and multicast systems.
>

"secure routing architecture", for consistency with the sentence above?

>    - Document specific routing functionality modules with this

s/with/within/?

>      architecture designed to address specific secure routing
> requirements as they are determined by the RPSEC Working Group
>
> Goals and Milestones:
>
-> "architecture"?
> Dec-06    Submit secure origination mechanism as a Proposed Standard

Suggest using exactly the same words to describe the documents in each 
milestone that refers to them. Saves confusion.

> Jan-06    Evaluate progress, recharter with new goals or shutdown.

No more comments....

---

From: Geoff Huston <[email-masked]>
Date: Mon, 28 Nov 2005 07:19:53 +1100

Secure Inter-Domain Routing (sidr)
Last Modified: 2005-11-28

Chair(s):
   TBD

Routing Area Advisor:
   TBD

Other Advisors:
   ? Security: TBD
   ? Routing: TBD

Mailing Lists:

   One of the areas of vulnerability for large scale Internet
   environments lies in the area of inter-domain routing. The basic
   security questions that can be posed regarding routing information
   is that of the validity of the address prefix being advertised, the
   validity of the originating Autonomous System Number, and the
   existence of an explicit permission from the address prefix holder
   to allow the prefix to be advertised from this origin. A related
   question concerns the level of trust than can be ascribed to
   attributes of a routed object in terms of their authenticity,
   including consideration of the AS Path attribute..

   The scope of work in the SIDR working group is to formulate an
   extensible interdomain routing security architecture that is capable
   of supporting incremental additions to a security framework for
   interdomain routing.

   The scope of work in the SIDR working group is to formulate an
   extensible architecture for an interdomain routing security
   framework. This framework must be capable of supporting incremental
   additions of functional components. As and when interdomain routing
   security requirements are completed within the RPSEC Working Group,
   these requirements will be defined within the SIDR framework as
   functional components of a secure interdomain routing system.

   The scope or work will include the definition of certification
   objects that can be used to support the distribution of
   authentication information. Both strict hierarchical and distributed
   non-hierarchical trust systems are intended to be supported within
   this framework.

     routing architecture

   - Document specific routing functionality modules within this
     architecture that are designed to address specific secure routing
     requirements as they are determined by the RPSEC Working Group

Goals and Milestones:

           within this architecture

Jan-07    Evaluate progress, recharter with new goals or shutdown.

---

From: Geoff Huston <[email-masked]>
Date: Mon, 28 Nov 2005 07:19:00 +1100

>asked in routing is "if I believe this information, will the result be 
>what I want it to be" - but authenticity of the information is usually a 
>good start.... unless others have alternative language to propose, this is OK.

Personally  I find the definition of "what I want it to be" a far more 
troublesome phrase to pin down!. I have not seen alternative language, and 
the language used here draws on many of the commentaries I've seen and 
heard on this topic.

>Q: should "a routed object" be "a routing information object" or "an 
>object passed in a routing protocol"? To me, "a routed object" is a 
>packet, and that doesn't seem to make sense....

I thought about this and to me a "routed object" was the expression I was 
searching for. Its a relatively minor thing I admit but I was looking to 
describe the basic route object (the prefix) and distinguishing that from 
the attributes that a routing system may permit to be associated with the 
basic object. "an object passed in a routing protocol" is perhaps the best 
equivalent phrase, but for a WG charter text that's getting to be a bit of 
a mouthful isn't it!

>functions described <where?>.

I'd prefer to omit the "but should at the outset..." phrase, as the area of 
agreement, concerning secure origination is not described in a standalone 
RPSEC document.

>Q: Does the work involve revisiting RFC 3779 AS number/address range 
>certs, using these certs, or ignoring these certs and do something 
>completely different?

I's my assumption that this work is a normative reference to the SIDR work. 
I've not heard anyone suggest redoing this work in a different way until 
your note above.

>"secure routing architecture", for consistency with the sentence above?

yes

>>    - Document specific routing functionality modules with this

yes

>>Jan-06    Evaluate progress, recharter with new goals or shutdown.

thanks for these

    Geoff

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 27 Nov 2005 21:28:03 +0100

--On mandag, november 28, 2005 07:19:00 +1100 Geoff Huston <[email-masked]> 
wrote:

> basic object. "an object passed in a routing protocol" is perhaps the
> best equivalent phrase, but for a WG charter text that's getting to be a
> bit of a mouthful isn't it!

a "route object" would do it for me... but are you saying that you think 
"route object" means "prefix"?

>> extensible  architecture for an interdomain routing security framework.
>> This framework  must be capable of supporting incremental additions of
>> new functional  components, but should at the outset be capable of
>> supporting the security  functions described <where?>.
>
> I'd prefer to omit the "but should at the outset..." phrase, as the area
> of agreement, concerning secure origination is not described in a
> standalone RPSEC document.

no problem for me, but it seems strange to describe an initially-empty 
framework...

>>> authentication
> I's my assumption that this work is a normative reference to the SIDR
> work. I've not heard anyone suggest redoing this work in a different way
> until your note above.

That seems like a Good Thing to me - should the language perhaps read

  The scope of work will include describing the use of certification
  objets for supporting the distribution of authentication information

so that we avoid saying "defining objects" where we think that these are 
already defined?
("the scope or work" is, I assume, a typo)

---

From: Geoff Huston <[email-masked]>
Date: Mon, 28 Nov 2005 07:51:50 +1100

>"route object" means "prefix"?

route object it is then

I did imply that 'route object' is the 'primitive' and it is adorned with 
attributes. But I sugest that we are perhaps wandering in a direction that 
is not getting us close to closure on a charter text - so if 'route object' 
works for you, it also works for me!

>no problem for me, but it seems strange to describe an initially-empty 

If the RPSEC WG managed to come to closure on their requirements document 
then we'd have a document to refer to. But until then there's no agreed 
document. The issue here is that RPEC has come to closure on origination, 
but remain unable to resolve the AS Path issues to a consensus text.

>("the scope or work" is, I assume, a typo)

yep - good suggestion - thanks!

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Mon, 28 Nov 2005 19:20:55 +1100

(included Harald's suggestions in this version)

Secure Inter-Domain Routing (sidr)
Last Modified: 2005-11-28 (V3)

Chair(s):
   TBD

Routing Area Advisor:
   TBD

Other Advisors:
   ? Security: TBD
   ? Routing: TBD

Mailing Lists:

   attributes of a route object in terms of their authenticity,

   The scope of work will include describing the use of certification
   objects for supporting the distribution of authentication
   information. Both strict hierarchical and distributed non-
   hierarchical trust systems are intended to be supported within
   this framework.

   The scope of work is limited to inter-domain router-to-router
   protocols only, for both unicast and multicast systems.

   - Document the use of certification objects within this secure
     routing architecture

Goals and Milestones:

Nov-06    Submit description of use certificate objects by this
           architecture as an Informational RFC

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 28 Nov 2005 00:41:30 -0800 (PST)

I still think you need to specify that work will include information
on how to publish certification objects. Either have this as separate
point below or addition to existing one.

>  - Document the use of certification objects within this secure

Possibly change to:

   - Document use and publication of certification objects within
     secure interdomain routing architecture

---

From: Geoff Huston <[email-masked]>
Date: Mon, 28 Nov 2005 20:36:23 +1100

>     secure interdomain routing architecture

Now one way or another we are talking about certificate repositories. What 
did you have in mind to specify here above and beyond normal repository 
operation?

thanks,

  Geoff

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 28 Nov 2005 04:08:16 -0800 (PST)

> did you have in mind to specify here above and beyond normal repository 

That is pretty much it. I do not see it clearly spelled out in the
charter that we would work on specifying access to (or at least linking 
rules for specifying PKI repository) PKI repositories and format of the 
data that is to be retrieved. There are actually quite a number of ways
to run a repository or certificate verification service that have been 
developed (plus add related issues and formats for publication of CRL
data as well), these are just a few these:
  SCVP (draft-ietf-pkix-scvp-21.txt)
  DVCS (RFC3029)
  OSCP (RFC2560)
  PKIXREP locator (draft-ietf-pkix-pkixrep-04.txt)
  HTTP Certificate Store (draft-ietf-pkix-certstore-http-09.txt)
  LDAP Certificate server
  PGP (HTTP based) key & certificate server
  etc.
And it may well be that none of the above will work because one of the key
issues is that BGP (like DNS) is a base protocol so one can not fully rely 
on some "higher" application protocol as part of BGP route establishment
(see also SBGP & soBGP and compare how they propose to store cert data).

I think info on considerations and issues involved in setting up and
running repositories that would be used for BGP security should be
considered and documented as well at least in some way.

Also the format for certificates and any necessary extensions are all 
in scope (i.e. if we decide we need extension of RFC3779) and this
I also see as publication-related issue.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Tue, 29 Nov 2005 10:40:40 +1100

At 11:08 PM 28/11/2005, william(at)elan.net wrote:

>>Now one way or another we are talking about certificate repositories. 
>>What did you have in mind to specify here above and beyond normal 
>>repository operation?
>
>Also the format for certificates and any necessary extensions are all in 
>scope (i.e. if we decide we need extension of RFC3779) and this

I am unsure how nmuch of this belongs in a SIDR charter and how much 
belongs in a security area as a work item and how much is beyond the scope 
of standards-related activities. For a charter I'm personally more 
comfortable with the more general phrase of

" Document the use of certification objects within this secure routing 
architecture"

and not specifying the form of repository nor the form of repository access 
as charter work items at this point in time.

regards,

     Geoff

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 28 Nov 2005 15:57:53 -0800 (PST)

On Tue, 29 Nov 2005, Geoff Huston wrote:

> I am unsure how nmuch of this belongs in a SIDR charter and how much belongs 
> in a security area as a work item and how much is beyond the scope of

As I said before I view SIDR work as something that is more security
centric then routing but like others I personally dont care that much
if its officially under security or under routing area. But in general
IETF usually has security area WGs work on security additions to other 
protocols (when its whole WG rather then one document in WG that is
mostly working on something else).

> standards-related activities. For a charter I'm personally more comfortable 
> with the more general phrase of

> as charter work items at this point in time.

Strongly disagree. You can not attempt global deployment unless you deal 
with repository access issues.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Tue, 29 Nov 2005 15:56:50 +1100

At 10:57 AM 29/11/2005, william(at)elan.net wrote:

>>>issues is that BGP (like DNS) is a base protocol so one can not fully 
>>>rely on some "higher" application protocol as part of BGP route establishment
>>belongs in a security area as a work item and how much is beyond the scope of
>
>>standards-related activities. For a charter I'm personally more 
>>and not specifying the form of repository nor the form of repository 
>>access as charter work items at this point in time.
>

This is an effort at creating a set of techology standards, not a specific 
deployment specification for a particular networked environment. Given the 
diversity of potential deployment scenarios across various forms of 
Internet environments I think that some division of the activity is 
entirely appropriate and necessary, and the generation of deployment 
profiles may well be an outcome of such a division of effort - but from the 
point of view of specification of technology standards and the charter for 
such an activity, I believe it to be appropriate to will pass on this draft 
charter to the ADs with the wording as  proposed above.

Geoff

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 28 Nov 2005 17:34:10 +0100

At 09:20 28/11/2005, Geoff Huston wrote:

>   environments lies in the area of inter-domain routing.  [...]

I like the charter as it is, but would add two tasks:

1. Whatever this group builds, will have to be deployed by operators.
    This group should explicitly ask operators if the proposed solutions
    can be easily implemented against acceptable costs (for them).  Any
    solution that fails this requirement, won't be deployed.  Work
    to define it is essentially lost.

2. The group should liaise with other efforts in this area.  In the US,
    DHS is active in this field, there might be more.  We need a solution
    that is acceptable to all parties in this field.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad.                 (Tom Verlaine)

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 28 Nov 2005 22:14:30 -0800 (PST)

On Tue, 29 Nov 2005, Geoff Huston wrote:

> deployment specification for a particular networked environment.

How many BGP networking environments do you know (especially those 
that have "trust issues" and need security as far as who can can
announce what ip routes by what ASNs)?

This is not OSPF or ISIS where each company has its own independent
network that it configures the way it wants and can use various
scenarios on how to run it. BGP use is almost entirely used as primary
routing protocol for one very large network we call Internet (yes, there 
are couple organizations that use BGP in their labs independent of the 
global internet, but I do not believe such use is of serious matter for
this security work).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Tue, 29 Nov 2005 17:13:45 +1100

Yes, they are useful (and necessary) tasks.

   Geoff