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

From: [email-masked]
Date: Thu, 20 Jul 2006 12:40:12 -0400 (EDT)

>  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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

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

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

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

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

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

> true that the security information is of no use whatsoever on the  

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.

---

From: Geoff Huston <[email-masked]>
Date: Fri, 21 Jul 2006 08:01:22 +1000

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

---

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

> _requirement_ with respect to discontiguous security domains had already 

Geoff,

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

Curtis

---

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

Geoff,

Curtis

---

From: Geoff Huston <[email-masked]>
Date: Fri, 21 Jul 2006 10:50:40 +1000

My note was attempting to draw a distinction between specification of 
requirements and heading into topics that appear to be solution design.

While I am personally of the view that the requirement has been adequately 
identified, I appreciate that this is not a common position within the 
context of this WG at this stage.

Geoff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Jul 2006 11:47:49 -0400

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

> true that the security information is of no use whatsoever on the other

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