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

From: [email-masked]
Date: Fri, 21 Jul 2006 13:17:56 -0400 (EDT)

Iljitsch van Beijnum said:

>> 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.
>
>I strongly disagree with the notion that this should be a requirement.

I also disagree with making the statement a requirement.  (And I sure
don't know how to meet or judge a "useful, in some way" 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.

I agree with this paragraph, with one reservation - I believe that, for
most mechanisms, it would be difficult to decide whether the information
could never, ever be useful on the other side of a gap.  There are
always operational means of deciding trust outside of technological
mechanisms.  I agree that the tradeoff should be analyzed, considered,
and expressed for any suggested mechanism.  Certainly the likelihood of 
usefulness might influence the engineering decision at mechanism design 
time of whether to permit carrying the info through the gap.  And - has 
there ever been anything that was NOT configurable by the operator?

Note: even for optional transitive attributes, the BGP spec says that
they SHOULD be propogated, not MUST.  Probably for the same space/
bandwidth/etc concerns we're talking about here.  I imagine that means
that there are configuration options in implementations that permit the
operator to indicate whether to drop such an option or not.  So there
may be no need to decide at design time whether a new mechanism should 
be carried across gaps - that decision is in the hands of the operator 
anyway.

--Sandy

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 21 Jul 2006 21:24:06 +0200

> time of whether to permit carrying the info through the gap.

I think we're moving towards the following set of choices:

1. Make the choice of backward/non-backward compatible encoding and/ 
or the dissemination of security information towards non-upgraded  
peers operator configurable, or
2. Defer the choice until later when, presumably, the tradeoffs will  
be better understood, or
3. Present an in-depth analysis of all the relevant factors to  
support the choice made

Agree?

> And - has there ever been anything that was NOT configurable by the  
> operator?

Sure, lots of stuff.

> operator to indicate whether to drop such an option or not.

I can't say that I've ever encountered such a mechanism, but I have  
to say that I never looked for it so I can't claim that it doesn't  
exist.

But I think since there are only very few optional path attributes,  
there was never a great need to filter out unknown ones.