draft-ietf-rpsec-bgpsecrec-06.txt

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


If this is to be a requirement, I'd like to inquire as to
the exact
meaning here.

By "new BGP messages", do we mean messages in
the BGP definition
of message types?  So new attributes would not be considered
new messages?

BGP has a mechanism for dealing with new attributes without
requiring
negotiation of same - define the attribute as optional
transitive and
it can be passed along without being recognized.  Are we
setting a higher
bar for security mechanisms, and if so, why?

I'm also not sure what the "new ways to interpret or
handle existing
BGP messages" means and why it is of concern. 
"Drop bogus updates"
could be a new way to interpret messages, but such
interpretation should
not even by seen by a clueless recipient, so I don't see
why it would
require negotiation.  Yes, there could be handling of
existing messages that
would result in changes in what the recipient would see and
so might
affect the recipient, even if the recipient was going to
ignore them
(bandwidth, etc.).  But making this a requirement that
covers *all*
changes in handling is too broad.

The statement as made prohibits new security information
from
being carried through a clueless area to a clueful AS on the
other side.
Is that what is desired here?

An AS might have reasons for believing that an AS that was
not participating
in a security mechanism might still be expected to retain
the security
properties the security mechanism was protecting.  So it is
not necessarily
true that the security information is of no use whatsoever
on the other
side of a gap.

--Sandy

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

On 20-jul-2006, at 18:40, sandytislabs.com wrote:

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

> If this is to be a requirement, I'd like to inquire as
to the exact
> meaning here.

> By "new BGP messages", do we mean messages
in the BGP definition
> of message types?

That's what I meant, yes.

> So new attributes would not be considered new messages?

No, new attributes would be considered new attributes.  

> BGP has a mechanism for dealing with new attributes
without requiring
> negotiation of same - define the attribute as optional
transitive and
> it can be passed along without being recognized.

Right.

As I've tried to say before: we should only use this
mechanism for  
information which is still useful after traversing one or
more non- 
upgraded hops AND only if we can be reasonably sure that
currently  
deployed routers won't run into trouble because of the
extra memory  
required to store this information.

> I'm also not sure what the "new ways to
interpret or handle existing
> BGP messages" means and why it is of concern. 
"Drop bogus updates"
> could be a new way to interpret messages, but such
interpretation  
> should
> not even by seen by a clueless recipient, so I don't
see why it would
> require negotiation.  Yes, there could be handling of
existing  
> messages that
> would result in changes in what the recipient would see
and so might
> affect the recipient,

I mostly meant new message types, but I can imagine
modifying  
existing message types or the behavior after receiving an
existing  
message if the new security mechanisms are in use. For
instance, it  
may be necessary to increase the BGP message size to
accommodate the  
extra information that needs to be carried. Obviously, these
larger  
messages shouldn't be sent to neighboring routers unless
we're sure  
that they support those.

> even if the recipient was going to ignore them
> (bandwidth, etc.).

???

I don't think ignoring messages is valid behavior in BGP.

> The statement as made prohibits new security
information from
> being carried through a clueless area to a clueful AS
on the other  
> side.
> Is that what is desired here?

Only in new message types or modified current message types.
This is  
certainly desired since sending this information to an
unsuspecting  
router may lead to all kinds of upredictable results.
Encoding the  
information in new path attributes is a different matter,
existing  
implementations should handle those, but see above.

> An AS might have reasons for believing that an AS that
was not  
> participating
> in a security mechanism might still be expected to
retain the security
> properties the security mechanism was protecting.  So
it is not  
> necessarily
> true that the security information is of no use
whatsoever on the  
> other
> side of a gap.

If I speak to you in a language you don't understand the
relevance of  
the message is immaterial, you're not going to understand
it.



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

Is this really part of a _requirements_ discussion, or it is
heading off 
into an _implementation considerations_ discussion? I
thought the 
_requirement_ with respect to discontiguous security domains
had already 
been identified.

Regards,

   Geoff



At 07:46 AM 21/07/2006, Iljitsch van Beijnum wrote:
>On 20-jul-2006, at 18:40, sandytislabs.com wrote:
>
>>>  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.
>
>>If this is to be a requirement, I'd like to inquire
as to the exact
>>meaning here.
>
>>By "new BGP messages", do we mean
messages in the BGP definition
>>of message types?
>
>That's what I meant, yes.
>
>>So new attributes would not be considered new
messages?
>
>No, new attributes would be considered new attributes. 

>
>>BGP has a mechanism for dealing with new attributes
without requiring
>>negotiation of same - define the attribute as
optional transitive and
>>it can be passed along without being recognized.
>
>Right.
>
>As I've tried to say before: we should only use this
mechanism for
>information which is still useful after traversing one
or more non- 
>upgraded hops AND only if we can be reasonably sure that
currently
>deployed routers won't run into trouble because of the
extra memory
>required to store this information.
>
>>I'm also not sure what the "new ways to
interpret or handle existing
>>BGP messages" means and why it is of concern. 
"Drop bogus updates"
>>could be a new way to interpret messages, but such
interpretation
>>should
>>not even by seen by a clueless recipient, so I
don't see why it would
>>require negotiation.  Yes, there could be handling
of existing
>>messages that
>>would result in changes in what the recipient would
see and so might
>>affect the recipient,
>
>I mostly meant new message types, but I can imagine
modifying
>existing message types or the behavior after receiving
an existing
>message if the new security mechanisms are in use. For
instance, it
>may be necessary to increase the BGP message size to
accommodate the
>extra information that needs to be carried. Obviously,
these larger
>messages shouldn't be sent to neighboring routers
unless we're sure
>that they support those.
>
>>even if the recipient was going to ignore them
>>(bandwidth, etc.).
>
>???
>
>I don't think ignoring messages is valid behavior in
BGP.
>
>>The statement as made prohibits new security
information from
>>being carried through a clueless area to a clueful
AS on the other
>>side.
>>Is that what is desired here?
>
>Only in new message types or modified current message
types. This is
>certainly desired since sending this information to an
unsuspecting
>router may lead to all kinds of upredictable results.
Encoding the
>information in new path attributes is a different
matter, existing
>implementations should handle those, but see above.
>
>>An AS might have reasons for believing that an AS
that was not
>>participating
>>in a security mechanism might still be expected to
retain the security
>>properties the security mechanism was protecting. 
So it is not
>>necessarily
>>true that the security information is of no use
whatsoever on the
>>other
>>side of a gap.
>
>If I speak to you in a language you don't understand
the relevance of
>the message is immaterial, you're not going to
understand it.
>
>
>
>_______________________________________________
>RPSEC mailing list
>RPSECietf.org
>https://
www1.ietf.org/mailman/listinfo/rpsec



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

In message <6.2.0.14.2.20060721075854.0328d968kahuna.telstra.net>
Geoff Huston writes:
>  
> Is this really part of a _requirements_ discussion, or
it is heading off 
> into an _implementation considerations_ discussion? I
thought the 
> _requirement_ with respect to discontiguous security
domains had already 
> been identified.
>  
> Regards,
>  
>    Geoff


Geoff,

I think the requirements are underspecified.  Apparently
other do too
and that is why there is a discussion.

Curtis


> At 07:46 AM 21/07/2006, Iljitsch van Beijnum wrote:
> >On 20-jul-2006, at 18:40, sandytislabs.com wrote:
> >
> >>>  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.
> >
> >>If this is to be a requirement, I'd like to
inquire as to the exact
> >>meaning here.
> >
> >>By "new BGP messages", do we mean
messages in the BGP definition
> >>of message types?
> >
> >That's what I meant, yes.
> >
> >>So new attributes would not be considered new
messages?
> >
> >No, new attributes would be considered new
attributes.  
> >
> >>BGP has a mechanism for dealing with new
attributes without requiring
> >>negotiation of same - define the attribute as
optional transitive and
> >>it can be passed along without being
recognized.
> >
> >Right.
> >
> >As I've tried to say before: we should only use
this mechanism for
> >information which is still useful after traversing
one or more non- 
> >upgraded hops AND only if we can be reasonably sure
that currently
> >deployed routers won't run into trouble because of
the extra memory
> >required to store this information.
> >
> >>I'm also not sure what the "new ways to
interpret or handle existing
> >>BGP messages" means and why it is of
concern.  "Drop bogus updates"
> >>could be a new way to interpret messages, but
such interpretation
> >>should
> >>not even by seen by a clueless recipient, so I
don't see why it would
> >>require negotiation.  Yes, there could be
handling of existing
> >>messages that
> >>would result in changes in what the recipient
would see and so might
> >>affect the recipient,
> >
> >I mostly meant new message types, but I can imagine
modifying
> >existing message types or the behavior after
receiving an existing
> >message if the new security mechanisms are in use.
For instance, it
> >may be necessary to increase the BGP message size
to accommodate the
> >extra information that needs to be carried.
Obviously, these larger
> >messages shouldn't be sent to neighboring routers
unless we're sure
> >that they support those.
> >
> >>even if the recipient was going to ignore them
> >>(bandwidth, etc.).
> >
> >???
> >
> >I don't think ignoring messages is valid behavior
in BGP.
> >
> >>The statement as made prohibits new security
information from
> >>being carried through a clueless area to a
clueful AS on the other
> >>side.
> >>Is that what is desired here?
> >
> >Only in new message types or modified current
message types. This is
> >certainly desired since sending this information to
an unsuspecting
> >router may lead to all kinds of upredictable
results. Encoding the
> >information in new path attributes is a different
matter, existing
> >implementations should handle those, but see above.
> >
> >>An AS might have reasons for believing that an
AS that was not
> >>participating
> >>in a security mechanism might still be expected
to retain the security
> >>properties the security mechanism was
protecting.  So it is not
> >>necessarily
> >>true that the security information is of no use
whatsoever on the
> >>other
> >>side of a gap.
> >
> >If I speak to you in a language you don't
understand the relevance of
> >the message is immaterial, you're not going to
understand it.
> >
> >
> >
> >_______________________________________________
> >RPSEC mailing list
> >RPSECietf.org
> >https://
www1.ietf.org/mailman/listinfo/rpsec
>  
>  
>  
> _______________________________________________
> RPSEC mailing list
> RPSECietf.org
> https://
www1.ietf.org/mailman/listinfo/rpsec


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

Not to pick on Sandy's message in particular, but it saves
me
from responding to many messages in this thread:

On Thu, Jul 20, 2006 at 12:40:12PM -0400, sandytislabs.com wrote:
> If this is to be a requirement, I'd like to inquire as
to the exact
> meaning here.
> 
> By "new BGP messages", do we mean messages
in the BGP definition
> of message types?  So new attributes would not be
considered new messages?
> 
> BGP has a mechanism for dealing with new attributes
without requiring
> negotiation of same - define the attribute as optional
transitive and
> it can be passed along without being recognized.  Are
we setting a higher
> bar for security mechanisms, and if so, why?
> 
> I'm also not sure what the "new ways to
interpret or handle existing
> BGP messages" means and why it is of concern. 
"Drop bogus updates"
> could be a new way to interpret messages, but such
interpretation should
> not even by seen by a clueless recipient, so I don't
see why it would
> require negotiation.  Yes, there could be handling of
existing messages that
> would result in changes in what the recipient would see
and so might
> affect the recipient, even if the recipient was going
to ignore them
> (bandwidth, etc.).  But making this a requirement that
covers *all*
> changes in handling is too broad.
> 
> The statement as made prohibits new security
information from
> being carried through a clueless area to a clueful AS
on the other side.
> Is that what is desired here?
> 
> An AS might have reasons for believing that an AS that
was not participating
> in a security mechanism might still be expected to
retain the security
> properties the security mechanism was protecting.  So
it is not necessarily
> true that the security information is of no use
whatsoever on the other
> side of a gap.

A given implementation of a secure BGP routing system could
do any
number of these things.  Which things it does will depend on
exactly
whether or not it is interfacing with the
"public" BGP routing system
and what level of backward compatibility with stock RFC 4271
style
BGP we're doing.

Our current requirements have us trending toward
compatibility with
existing BGP.  This means that an implementation must
discuss what
it will do in order to inter-operate.  There is a strong
presumption
that secure inter-domain routing will be built on BGP. 
While I think
that's great since it'll leverage existing BGP code and
operator
experience, one could develop a mechanism that had BGP
routing semantics
that used completely different protocol transports.  As long
as
the RFC 4271-facing portion of the secure implementation
used existing
BGP message formats and semantics, we're golden.  We can
speculate
all day about what the internals of the routing system would
look like,
but that takes us away from requirements and moves us into
implementation.

-----

I'd like to spend a second talking about transport of the
security 
information in an implementation.  This has nothing to do
with requirements.

I believe everyone understands the concern of carrying
excess per-path
information in the global BGP.  We've had this discussion
as part of
the BGP L3VPNs.  That horse has been beaten enough. 

It is certainly possible to carry security information in
optional-transitive
path information.  The amount could vary: You can carry it
all, or you
could carry enough to let secure domains reconnect.  As an
example,
within the secure domain, you could carry all of your
information in
the relevant non-transitive path attributes.  At a border,
you could
append a optional-transitive attribute which served to
identify
the router (or some "security server") which
could provide security
information that may be dropped.

My real point is that we should stress on these issues as an
implementation
issue, not a requirements issue.

-- Jeff

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