draft-ietf-rpsec-bgpsecrec-06.txt

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
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> http://www.ietf.org/internet-drafts/draft-i
etf-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.

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

- --
riwcisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFEtqSaER27sUhU9OQRAlCuAKCYxxGVam9PzWx5zuTPWrR1GWwGEgCg
7uli
QYvOFZMoWyL7hICz/MqAnf0=
=onsg
-----END PGP SIGNATURE-----

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

At 05:52 AM 14/07/2006, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
> > http://www.ietf.org/internet-drafts/draft-i
etf-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.
>
>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?

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



_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

At 3:52 PM -0400 7/13/06, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>>  http://www.ietf.org/internet-drafts/draft-i
etf-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.
>
>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

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

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

On 14-jul-2006, at 8:58, Geoff Huston wrote:

>> 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?

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

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.

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

>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 I find problematic here is that the formulation I
referred to
assumed no such thing.


>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?


You  may care to read what I _actually_ posted.



_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

On Fri, 14 Jul 2006, Geoff Huston wrote:

>> > http://www.ietf.org/internet-drafts/draft-i
etf-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.

<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

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

On 14-jul-2006, at 21:27, Geoff Huston wrote:

>> 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 I find problematic here is that the formulation I
referred to
> assumed no such thing.

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.

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

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

>  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

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 can traverse intermediate routers which don't
support the
>  new format.

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.

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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

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:

  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.

  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

- --
riwcisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFEv35rER27sUhU9OQRAjCKAKDBrinJjqnpUujJSNt0w+RgrdDoRACe
LQwX
ZuJLKEaGG3RadRs//3brrgI=
=sTHh
-----END PGP SIGNATURE-----

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec