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

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Jul 2006 16:53:07 -0400

A comment on something in http://www.ietf.org/internet-drafts/draft- 
ietf-rpsec-bgpsecrec-06.txt

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

What this says is that if I have routers A and C that support the new  
security stuff, and B in the middle, that doesn't, the new security  
stuff must be encoded such that it can pass router B in the middle  
without confusing it. That is quite a hard thing to do, and I don't  
think it's actually worth it.

First, consider the case of iBGP. In traditional iBGP, there is a  
full mesh between all the routers, so there is never a need to  
communicate security information between two upgraded router through  
a non-upgraded router since all routers talk to all other routers  
directly. This gets more complex with confederations and route  
reflectors, but I think in those cases it's not an undue requirement  
to upgrade certain routers such as the route reflectors first in  
order to make the transition go smoothly without the capability  
indicated above.

With eBGP, the situation where there is a non-upgraded router between  
two upgraded routers means that seen from at least one of the ASes  
involved, the BGP peer is a non-upgraded one in a different AS, so  
it's impossible to determine whether this router is propagating  
correct information and/or propagate information correctly, so the  
extra security that's supposed to be provided by the new mechanisms  
is reduced or even absent. In these cases,  would prefer to see a  
situation where the upgraded parts of the network are contiguous.

Not requiring backwards compatible encoding allows more flexibility  
in designing the security mechanisms. For instance, S-BGP fullfils  
the requirement and encodes all information in path attributes, while  
soBGP doesn't and puts the information in a new BGP message, which  
allows more flexibility.

Iljitsch

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

---

From: Russ White <[email-masked]>
Date: Thu, 13 Jul 2006 15:52:58 -0400

> http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-06.txt
> 
>       information carried through a mixed security environment.  Message
>       formatting in a fully secured environment MAY be handled in a non-

It may be more reasonable to say something like:

"A BGP security mechanism MUST be designed such that it can be used in
discontiguous sections of the network. A peer running any such such
security mechanism MUST interoperate with a peer not running the
mechanism so normal routing is not disrupted at the connection points
between peers running the security mechanism and not running the
security mechanism."

It's not perfect, but it might express what the real reason is behind
this requirement better?

:-)

Russ

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

---

From: Geoff Huston <[email-masked]>
Date: Fri, 14 Jul 2006 22:58:23 +1000

At 05:52 AM 14/07/2006, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>

I'm not sure that your intent is clear - one way to meet your formulation
of the requirement is to drop all security-extension material at the interface
with the non-equipped peer. Is this an intentional option in your proposed
wording? An alternative is that you want to express that security information
should be preserved across non-equipped path sectors, and that the
information and that when the information re-enters an equipped peer
it can be 'revived' (with the knowledge that there has been a discontinuity
in the security-aware path).

regards,

    Geoff

---

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Jul 2006 11:05:28 -0400

>It's not perfect, but it might express what the real reason is behind

I think your reformulated text is clearer in terms of the need to be 
able to specify whether a given peer is or is not running the 
security mechanism.  However, like Geoff, I am still bothered a bit 
by the first line, because there is no clear description of what one 
expects to get in the way of security services from discontinuous 
deployment.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Jul 2006 10:54:17 -0400

> I'm not sure that your intent is clear

I agree, it's still possible to interpret this in different ways.

> one way to meet your formulation

The latter option is exactly the one I find problematic because it  
assumes that the security information is carried in existing fields,  
i.e. path attributes, which I fear is a big burden on the BGP protocol.

What we need to think about is when two parts of the network where  
the new security mechanisms are deployed are separated by un-upgraded  
routers, to what degree do we want security advantages to carry over  
from one secure part to the other?

Obviously any kind of path security will be compromised but some kind  
of AS/prefix mapping security could be maintained. Maybe this is a  
good idea, but I would rather not require it without knowing the  
tradeoffs.

---

From: Geoff Huston <[email-masked]>
Date: Sat, 15 Jul 2006 05:27:22 +1000

>i.e. path attributes, which I fear is a big burden on the BGP protocol.

What I find problematic here is that the formulation I referred to
assumed no such thing.

>from one secure part to the other?

You  may care to read what I _actually_ posted.

---

From: Russ White <[email-masked]>
Date: Fri, 14 Jul 2006 16:45:37 -0400

> able to specify whether a given peer is or is not running the security
> mechanism.  However, like Geoff, I am still bothered a bit by the first
> line, because there is no clear description of what one expects to get
> in the way of security services from discontinuous deployment.

Actually, I think there are actually two things going on in this
section, and we might need to separate them, and consider them
separately (?). They seem to be:

- -- How a BGP speaker should react when running security mechanism x, and
connecting to a BGP speaker that doesn't run that security mechanism.

- -- Should a security mechanism be able to be deployed in a noncontiguous
manner?

Perhaps, if we split these two, we could come to some good wording for
them separately? Since this is in the incremental deployment section, is
the first sense really applicable in that area, or only the second?

:-)

Russ

- --

---

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

>the first sense really applicable in that area, or only the second?

I think both are applicable here and should be split apart to 
increase clarity. For issue #2 there is the other question, one that 
I raised, i.e., what do we require of a solution that is deployed in 
a noncontiguous fashion?  Do we have a way to characterize that or 
are we silent because it will be solution dependent?

Steve

---

From: Russ White <[email-masked]>
Date: Sat, 15 Jul 2006 09:13:45 -0400

>> Actually, I think there are two things going on in this
> I think both are applicable here and should be split apart to increase
> clarity. For issue #2 there is the other question, one that I raised,
> i.e., what do we require of a solution that is deployed in a
> noncontiguous fashion?  Do we have a way to characterize that or are we
> silent because it will be solution dependent?

That's a big issue--how do you characterize that? Maybe it's better to
remain silent on it, but we should probably take a poll of the list, to
see how folks think about it....

So, to the list: Do we want to try and craft language to talk about
solutions being noncontiguously deployable, or should the draft remain
silent on this point?

:-)

Russ

- --

---

From: Stefan Mink <[email-masked]>
Date: Tue, 18 Jul 2006 01:41:37 +0200

Hi all,

> solutions being noncontiguously deployable, or should the draft remain

I hate the answer, but: it depends :]

authentication data (e.g. authentication the path attribute or all the
attribute of a route) is pretty much worthless from a security point
of view when it traversed non-secured ASes (who changed what?). Somewhat
or partially authenticated data doesn't help you..

origin authorization data is different here: it still helps although
it travered non-secured ASes; (as long as we don't allow to symmetric
signatures ala hash trees that depend on a contiguous application of the 
security mechanism).

redistribution authorization data on the other hand is useless when
its not contiguous. It doesn't really helps me to know that the
penultimate AS was authorized to pass the route on the the last AS
in the path if I can not check if that one is allowed to give me
this route...

In the end its rather a question of how puristic your standpoint
is and what its worth to you in terms of money: do you only want to
get informations that help you for sure in terms of security or are
you in favor of a solution that may cost you initially more for
unusable information, but it speeds up the global deployment process.

My personal opinion: speed the process up. We'll be decades late
anyway ;)

Stefan

---

From: Tony Tauber <[email-masked]>
Date: Tue, 18 Jul 2006 15:19:19 -0700 (PDT)

>> >       UPDATES can traverse intermediate routers which don't support the

<snip>
> you want to express that security information should be preserved
> across non-equipped path sectors, and that the information and that
> when the information re-enters an equipped peer it can be 'revived'
> (with the knowledge that there has been a discontinuity in the
> security-aware path).
>
> regards,
>
>   Geoff

I like this.  How about:

  A BGP security mechanism MUST provide backward compatibility in
  the message formatting, transmission, and processing of routing
  information carried through a mixed security environment.  Message
  formatting in a fully secured environment MAY be handled in a non-
  backward compatible fashion though care must be taken to ensure
  UPDATES can traverse intermediate routers which don't support the
  new format.  Note that security information SHOULD be preserved
  across non-equipped path sectors, and when the information re-enters
  an equipped peer it can be 'revived' (with the knowledge that there
  has been a discontinuity in the security-aware path).

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Jul 2006 20:26:16 +0200

> What I find problematic here is that the formulation I referred to

Well, if you know of a way to carry new information through an  
unupgraded router other than in existing fields (= path attributes in  
the case of a BGP update) then I'm all ears.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Jul 2006 20:45:29 +0200

On 19-jul-2006, at 0:19, Tony Tauber wrote:

>  backward compatible fashion

If I were to nit pick I'd point out that what happens between A and B  
has no relation to what happens between B and C so this wording is  
not the greatest ever, but I guess it's good enough.

>  though care must be taken to ensure

Updates don't traverse intermediate routers.

The BGP spec is very particular about how newly defined path  
attributes must be handled, so what we need is:

   If a BGP security mechanism provides new BGP messages, or new ways
   to interpret or handle existing BGP messages, the new messages and
   the new semantics for the existing messages MUST NOT be used
   towards a particular neighboring BGP speaker unless the capability
   to use the new mechanism has been mutually announced during
   the BGP capability negotiation at session establishment.

And probably:

   The designers of a new BGP security mechanisms should carefully
   evaluate the tradeoffs of encoding security information in ways that
   allow it to be communicated from one BGP router implementing the
   mechanisms to another through an intermediate, non-upgraded router,
   versus dropping information on the borders between upgraded and
   non-upgraded parts of the network. The former is more appropriate
   when security benefits can be had even when intermediate routers
   are unaware of the new mechanism or part thereof (or even actively
   try to subvert them), while the latter is more appropriate when the
   mechanisms or a particular part thereof are rendered unusable when
   traversing an non-upgraded router. Another consideration is the
   amount of extra state that is injected into non-upgraded parts of
   the network by encoding security information in path attributes
   in Update messages, considering that many existing implementations
   do not support the capability to filter unknown path attributes.

And maybe:

   An updated BGP speaker MAY be configured to not operate in a backward
   compatible manner. In this case, a suitable error condition SHOULD
   be indicated in a BGP Notification message and the session be
   terminated.

---

From: Russ White <[email-masked]>
Date: Thu, 20 Jul 2006 09:00:27 -0400

>   do not support the capability to filter unknown path attributes.

I think the problem here is that the "sense of the list" is any proposed
security mechanism must have the former property--that the information
must be useful, in some way, even when it has passed through an AS
and/or peer that doesn't understand it.

At least that's my understanding....

I would say I like your initial paragraph wording, but the remainder of
Tony's (?).

Perhaps:

  Security information SHOULD be preserved
  across non-equipped path sectors, and when the information re-enters
  an equipped peer it can be 'revived' (with the knowledge that there
  has been a discontinuity in the security-aware path).

Or something of that type?

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Jul 2006 13:43:05 -0400

At 3:19 PM -0700 7/18/06, Tony Tauber wrote:
>...

I think this is ambiguous in several places, and too specific in others.

The allusion to "message formatting" seems ambiguous. It might mean 
that security data is sent via a new protocol on a new port, for 
example.  An UPDATE should be able to traverse a router that is not 
cognizant of the security technology, especially if the UPDATE is not 
carrying security data, or if the data is carried in a fashion 
consistent with BGP extension mechanisms, etc. The notion of security 
info being "revived" seems to imply a specific implementation 
approach, which is inappropriate for a requirements document of this 
sort.

I'm just noting how hard it is to generate good requirements text 
here, without imposing pre-conceptions on the solution space.

Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 Jul 2006 13:46:04 -0400

> Or something of that type?

Russ,

Hope this helps... feel free to use this and further wordsmith as
needed.

BPG security mechanisms differ in the following ways.

  1.  The scope of key distribution may be local or global.

    a.  A BGP security mechanism may use a transitive trust model,

    b.  A BGP security mechanism may use a form of authentication
        where keys are globally available and provide authentication
	information which is globally verifiable.

    c.  A BGP security mechanism may use both of the above using one
        scope for one type of information and another scope for
        another type of information.

  2.  A BGP security mechanisms may authenticate (or encrypte)
      different types of information including combination of the
      following.

    a.  A BGP security mechanism may provide authentication of
	the origin or or information related to the origin.

    b.  A BGP security mechanism may provide authentication of the BGP
        peer.

    c.  A BGP security mechanism may provide authentication of each AS
        in the path.

For example, a BGP security mechanism may provide authentication of
origin based on a key that is global is scope and rely on a transitive
authentication of the path using keys that are local in scope.

Ideally a BPG security mechanism would have the following properties.

  1.  The security information would be passed intact but
      uninterpreted across routers that did not support the same
      security mechanism.

  2.  A router implementing the security mechanism could distinguish
      between the following levels of trust.

    a.  A routing announcement was originated from a router that
        supported the same security mechanism, and traversed only
        routers that support the same security mechanism.

    b.  A routing announcement that was originated from a router that
        supported the same security mechanism, but traversed some
        routers that did not supported the same security mechanism.

    c.  A routing announcement that was originated from a router that
	did not supported the same security mechanism.

Any BGP security mechanism that supports only authentication of the
origin cannot distinguish between case "a" and "b" above.

Given the above properties, a router could implement policy which
considered the above levels of trust.  This routing policy could
determine whether to accept the route.  This routing policy could
modify the route selection.

If the route selection is modified based on level of trust, an entire
AS MUST implement the same route selection to avoid loops.  Orderly
transition of the AS must be considered.  Note that one way to
accomplish a transition that if free of persitant loops during the
transition is to make the route selection change conditional on the
absence of an intra-AS BGP community which is set on every route
during the transition, then removed.  The transition then occurs on a
per route basis as the BGP community is removed.  To accompish an
orderly transition using this method, BGP community MUST be supported
by the implementation in any policy that modifies the route selection.

Curtis

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Jul 2006 23:36:42 +0200

>   2.  A BGP security mechanisms may authenticate (or encrypte)

Encrypt?

I wouldn't want my routers to carry information that I can't inspect...

>       uninterpreted across routers that did not support the same

That is not necessarily an ideal situation. This means encoding the  
security information in path attributes, which means that BGP tables  
in existing routers will be inflated without benefit to those  
existing routers.

I'm not saying this is necessarily unacceptable, but it is certainly  
not "ideal" and should only be done after careful considerations of  
the consequences and the benefits.

It would certainly be a bad idea to carry information in path  
attributes that is invalidated as soon as it is relayed by a non- 
upgraded router. (This is just an example of a bad idea.)

> AS MUST implement the same route selection to avoid loops.

This is not a requirement in existing BGP and I don't see how adding  
security imposes this as a requirement.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Jul 2006 23:52:48 +0200

> and/or peer that doesn't understand it.

I strongly disagree with the notion that this should be a requirement.

Some information can be useful after having passed through a non- 
upgraded part of the network, some, by its nature, can't. The latter,  
IMO, should NOT be communicated to non-upgraded routers as it only  
imposes storage requirements without benefits. For the former, it's a  
tradeoff that I think should be presented clearly in an architecture  
or protocol spec document. Ideally, (again, IMO) this should be  
configurable by the operator.

(-:

---

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

In message <[email-masked]>
Iljitsch van Beijnum writes:

> configurable by the operator.

I agree with the above paragraph.  Is anyone taking notes on this
conversation?  [I hope its worth taking notes?]

Curtis

---

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

In message <[email-masked]>
> >   2.  A BGP security mechanisms may authenticate (or encrypte)

Not likely imho.  Ask Sandy?  :-)

I was just trying not to exclude the possibility that some attribute
of routing might be encrypted in the future, since I don't really know
what people interested in very high security would like to do
particularly in the future.  You never know though.  Approximate GPS
location of a mobile router would be encrypted if anyone every decided
they needed that.  Location could be used in routing.  [ <g> I have no
idea who might conceivably want that sort of feature or want to
encrypt it if they added it. :) ]

I know of no current requirement for this, just didn't want to exclude
it.

Did I really spell encrypt wrong.  Oops.

> I wouldn't want my routers to carry information that I can't inspect...

Do you block IPSEC flows too?  :-)

How would you know its encrypted if it was in an optional transitive
attribute that your router didn't understand?  And why would you care
if your big government customer needed it but you didn't?

> in existing routers will be inflated without benefit to those  

You are right in a sense.  But I disagree.

It depends on the size of these extra attributes.  Some of the
proposals add so much information that I don't see it as feasible
except in a small closed network.  If people want to define protocols
that no one will ever deploy and whose attributes will be tossed
that's their business.  They've been at it for a while though.

> upgraded router. (This is just an example of a bad idea.)

If authentication information is all that is added to BGP then tossing
*all* the authentication information is certainly a bad idea.

What might make sense is to toss any per hop path authentication
before advertising to a router that would not add its authentication.
That would make sense if policy was based only on prefering a route
with a completely authenticated path over one that is not complete but
did not prefer paths with less hops not authenticated over ones with
more hops not authenticated.  OTOH if a completely authenticated path
was not available a path with only AS from a small set of fairly well
trusted AS in it might be preferred over one with more untrusted AS.

Removing information because it won't be needed downstream could be
considered a configurable space optimization.  Sound like I need a
SHOULD in that paragraph, making it.

> >   1.  The security information SHOULD be passed intact but

Is that better?

> security imposes this as a requirement.

All routers must implement the same route selection algorithm.  That
is a requirement of plain old BGP.  The exact route selection
algorithm is defined in RFC4271.  This is stating that if within an AS
the route selection defined in RFC4271 is not used, it has to be the
same throughout the AS.  Another way to implement this requirement is
to set LOCAL_PREF based on the level of trust.  You certainly want
level of trust over AS Path length so it might be easier to put in a
knob that if tweaked puts level of trust (fully authenticated vs
partially authenticated).  Note that the paragraph from which you
pulled the first sentence starts with "If the route selection is
modified".

FYI -- What I had in mind as a "for example" was a military network
being fully authenticated and maybe having a few attributes encrypted
and passing them over the commercial internet.  Commercial providers
might be willing to carry the attributes but not support the
encryption and the military willing to use the commercial internet
paths for some traffic or in the event of outage.  For example if a St
Helens size volcano eruption occurred in Alaska (is there anything in
Alaska like that?  probably not) the military might like to use a
commercial internet path if the volcanic dust blocked their wireless
link or satelite communications (or took out their fiber laid down by
dog driven sleds - or whatever).

Curtis

---

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

Is that better?

Curtis

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jul 2006 09:41:09 -0400

>     c.  A BGP security mechanism may provide authentication of each AS

I think it is confusing to refer to "a BGP security mechanism" when 
referring to  all of these security issues. For example, one might 
use different means of authenticating a BGP peer in different 
contexts and this choice may be completely independent of a mechanism 
used to verify route origination on a global basis.

Steve

---

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

Just noticed this in a prior message.

In message <[email-masked]>
> Updates don't traverse intermediate routers.

Substiture "advertisements" for "updates".

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Jul 2006 15:26:54 -0400

> used to verify route origination on a global basis.

Steve,

What term would you prefer?

BTW.  In a transitive trust model there is no implication that all the
peers along the path used the same method to authenticate there peer,
just that they used *some* authentication method and was convinced
that the peer was who they claimed to be.  It would be possible to add
an optional non-transitive attribute indicating that a specific method
was used on the entire path.  If a router didn't understand that
attribute it would be dropped.  That functionality was not implied
anywhere above.

Curtis

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jul 2006 16:54:46 -0400

>attribute it would be dropped.  That functionality was not implied

What I objected to was the use of the term "BGP Security mechanism" 
to refer to what are a set of independent security mechanisms that 
need not be uniform and which may be largely independent of one 
another. I thought your example above was consistent with what I was 
trying to say, but then I saw the reference to a path attribute that 
attests to  what form of authentication was used on each hop.

The confusion arises because the peer authentication to which I was 
referring was what an (e)BGP router does to decide whether to accept 
an inbound UPDATE message as being from the indicated peer, at a low 
level.  This is a purely local example of peer authentication. Your 
example is also a valid instance of peer authentication, but one that 
arises only if one assumes reliance on transitive trust to 
authenticate a path. It is an example that makes sense only under one 
set of assumptions, and that's what confused me.

Steve

---

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

> set of assumptions, and that's what confused me.

Maybe we need some definitions.

  origin authentication - crypto authentication of the route
    origination.

  peer authentication - crypto authentication which provides
    additional assurance that the peer is who the peer claims to be.

  transitive trust model - the assumption that if each peering is
    autheticated and the origination was authenticated that the path
    is valid.

  per hop authentication - any mechanism where every transfer from
    peer to peer adds additional information or makes modifications to
    information that can be used to verify authenticity of the path.

Every hop reencrypting a token with their private key is not a
transitive trust model.  A transitive trust model is where if A trusts
information from B and B trust information from C then A trusts
information it got from B that B claims to have obtained from C, and
so on.

Reencrypting a token with a private key at each hop does insure that
the path is valid.  This insures that a rogue AS does not grab an
originated route or partial path and add its AS and pass that along to
disrupt routing.  It does not protect against the most common problem.
The origination was just plain "in error".  It does protect against
the accidental (or intentional) injection of something not even
vaguely related to that AS but so would a means of supporting origin
authentication and the use of transitive trust.

Whether you need to protect against such a rogue AS may depend on who
you are providing network service to - consumers, business, or DoD.

Curtis

---

From: Russ White <[email-masked]>
Date: Sun, 23 Jul 2006 08:19:04 -0400

>   origin authentication - crypto authentication of the route

I'm not certain why it has to be "encrypted," or "crypto?" I think most
all of the mechanisms currently proposed do use encryption based
signatures (or some such) to do this, but I don't see it as a
requirement, or part of the definition. Certainly there might be some
other way to do this that no-one has thought of yet....

>     autheticated and the origination was authenticated that the path

You can't put "and the path is valid" in here. Transitive trust doesn't
show anything about the path, at least as far as I can see.

>     information that can be used to verify authenticity of the path.

There are other ways to "validate a path" than "per hop authentication,"
- --at least two, and possibly, more, have been proposed. So, I don't
think it's valid to put that in this definition.

Of course, I don't know where you had planned on actually putting these
definitions.... :-)

Don't assume "one solution" or "one type of solution" in this
discussion--we are talking about requirements, not solutions, here.
While making some statement "x" about the AS Path may be desirable,
saying: "Doing X provides us with this security, so we should require
X," isn't.

:-)

Russ

- --

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 23 Jul 2006 14:12:58 -0400

> other way to do this that no-one has thought of yet....

This could say crypto or other authentication.

A routing registry is out of band authentication (which itself may be
protected by crypto to be of much use).

> show anything about the path, at least as far as I can see.

It does say "the assumption that ...".  Transitive trust just means
that if you heard it from a reliable source and they heard it from a
reliable source, its reliable.  It is not proven to be reliable, but
assumed to be reliable enough to use it.

Would you like to suggest better wording?

> think it's valid to put that in this definition.

I consider anything in which each hop (or AS hop) further encrypts
with their private key to be a form of adding or modifying information
as a means for others to verify authenticity.

> Of course, I don't know where you had planned on actually putting these

Neither do I.

I just gave them so that Steve Kent and I could carry on a meaningful
discussion.

> saying: "Doing X provides us with this security, so we should require

One way to see if the requirements are at all reasonable or complete
is to see how well they capture the benefits (or perceived benefits)
of various solutions proposed, under consideration, or in use.

Since we know we have conflicting requirements it *should* seem
obvious that we are going to have more than one solution and not all
solutions can meet all requirements.  If any two requirements are
conflicting, then no one solution could meet both.  Some providers or
institutions are going to prefer low memory and CPU impact solutions.
Others (Dod for example) are going to prefer stronger security.

The goal is not to end up with the set of requirements that specifies
our favorite solution.  The goal is to capture all requirements so we
can later figure out how to provide the best set of options in a set
of security mechanisms, some of which might be deployed widely, others
that might be deployed less widely but are still useful.

Curtis

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Jul 2006 02:34:37 -0400

Curtis,

I'm afraid I have some problems with every one of your proposed definitions.

>   origin authentication - crypto authentication of the route

I'm not sure this is what all of us mean :-). If some AS sends an 
advertisement for a prefix for which it is not authorized to 
originated a route, one would not consider that advertisement 
"authentic." So I think "origin authentication" ought to encompass 
the broader notion of an AS being authorized to originate the route 
in question.

>     additional assurance that the peer is who the peer claims to be.

typically this term is interpreted to mean that such assurance is 
provided only to the neighbors with whom the peer is in direct 
contact. is that also part of what you had in mind here?

>     autheticated and the origination was authenticated that the path

I think there are a lot of different views of what this term means. 
This WG has had trouble defining what a "valid" path is, so the 
conclusion is already problematic. Also, there is no mention of the 
prefixes being advertised.  Routes are paths plus prefixes and we're 
really interested in routes, so this definition does not go far 
enough in that direction.

>     information that can be used to verify authenticity of the path.

This is the opposite of what the security community generally means 
when the term "hop" is used in conjunction with the term 
"authentication." we usually contrast hop-by-hop or point-to-point 
with end-to-end when talking about security services.

>information it got from B that B claims to have obtained from C, and

Again, we're talking about signatures, not encryption here. But I do 
get the gist of the argument you're making.

>authentication and the use of transitive trust.

I suggest we avoid very specific references to solution techniques in 
our discussion, especially since the mechanism you described here 
does not correspond to any solution with which I am familiar :-).

Route origin authorization (not authentication) is a key element as a 
starting point, which is why the SIDR WG has begun there. Transitive 
trust, as a general notion, allows errors or attacks by an AS along a 
path to generate bogus routes. Remember that the AS operations 
personnel may or may not be complicit. a router may have been 
compromised, or a management workstation, etc. So, what I think you 
are suggesting is that origin authorization combined with transitive 
trust would address this most common set of errors/attacks.  I agree, 
but that does not mean that such a scheme is sufficient going forward.

>you are providing network service to - consumers, business, or DoD.

Because of the highly-connected nature of the public Internet, I'm 
not sure who the "you" is above. If I am an ISP and my customers want 
protection against rogue ASes (using the term broadly as I suggested 
in the previous paragraph), then I cannot provide such protection 
solely based on what I do as the ISP that serves these customers 
directly. Only of other ASes participate in the implementation of 
security measures can I meet the needs of my subscribers. That's why 
suggesting requirements that ignore such attacks ultimately restricts 
what any AS can do for its subscribers.

Steve