Subject: RE: [RPSEC] Discontiguous Deployment...

From: [email-masked]
Date: Mon, 24 Jul 2006 15:33:20 -0400 (EDT)

>Any such requirement should definitely be a case of restating the
>obvious, since any 'solution' failing to meet the requirement would, by
>definition, be useless.  ;-)

So is it useful or useless to state a requirement that a solution be useful?
:-)

--Sandy

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

---

From: Cat Okita <[email-masked]>
Date: Mon, 24 Jul 2006 16:12:30 -0400 (EDT)

> So is it useful or useless to state a requirement that a solution be useful?

I think it's useful to suggest specific ways in which a solution should
be useful, and otherwise useless ;>

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."

---

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

> So is it useful or useless to state a requirement that a solution  

Based on the evidence you can argue in either direction: too many  
solutions aren't useful, so either the requirement of usefulness  
would be useful, or maybe the requirement was already there even  
though the solution turned out useless; in that case the requirement  
of usefulness is useless.  :-(

Seriously, though: it doesn't make much sense to require something  
that we don't know to be useful. Just adding more and more  
requirements in the hope that a solution will accommodate them all  
and be perfect is a road that leads nowhere, as the IRTF routing rg  
and especially the multi6 wg can attest to.

---

From: Blaine Christian <[email-masked]>
Date: Thu, 27 Jul 2006 19:46:08 -0700

On Jul 24, 2006, at 1:06 PM, Iljitsch van Beijnum wrote:

> though the solution turned out useless; in that case the  
> requirement of usefulness is useless.  :-(
>

Just a thought (and no comment on your notes specifically Iljitsch) I  
have seen many notes on the term "useful".  The word is very vague  
and should be avoided in the draft.  When I agreed with Tony/Russ it  
was specifically regarding whether it was important to have the  
ability to deploy in a non-contiguous fashion.  This ability is  
highly important and should show incremental improvement in our  
ability to identify and manage to the sources of prefixes on the  
Internet (speaking with an ISP hat on of course).    Now, speaking  
with my enterprise hat.  I would also believe strongly in the ability  
to deploy in a non-contiguous fashion and show some incremental  
improvement in my ability to ensure the veracity of announcements  
received in a secured system.  For example, I could envision local  
pref'ing all inbound advertisements from secured AS's within my  
"insecure" AS and feeling like I have moved forward with my security  
by paying more attention to secured networks.

As to whether we should carry information in "opaque" mode within the  
Internet backbone providers whether or not they are "secure".  I am  
not so sure about this method.  Again with ISP hat on I can say it is  
highly, very highly, annoying to find some new hack perpetrated on my  
routing process without my knowledge.  This has caused rather major  
outages for me (and I suspect for many others) in the past.   I would  
warn against involving networks that did not "plan" on an additional  
increase in memory utilization etc...

Another note on useful.  I do agree with Iljitsch that unless this  
thing show some sort of use from the first network that implements it  
there are very good odds it will never leave the ground.  So yes!   
Please, let's make it useful <grin>.

Regards,

Blaine

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Jul 2006 10:35:54 +0200

On 28-jul-2006, at 4:46, Blaine Christian wrote:

> Just a thought (and no comment on your notes specifically Iljitsch)  
> I have seen many notes on the term "useful".  The word is very  
> vague and should be avoided in the draft.

I don't think it's vague, the problem is that different people find  
different things useful...

> When I agreed with Tony/Russ it was specifically regarding whether  
> it was important to have the ability to deploy in a non-contiguous  
> fashion.  This ability is highly important and should show  
> incremental improvement in our ability to identify and manage to  
> the sources of prefixes on the Internet (speaking with an ISP hat  
> on of course).

Maybe this whole "discontiguous" thing is a red herring. Suppose:

A-B-C-D-E

where everyone uses the new mechanisms except C. The assumption is  
that even though C is in the middle, A and B still find it useful to  
know security information about D and E. In the picture above the  
only way to accomplish that is to encode the security information  
such that C will carry it from D to B. But what if:

A-B-C-D-E
   |   |
   +---+

Assuming a model not unlike soBGP B and D could exchange security  
messages but not actual routing information over a multihop BGP  
session. This way, B and D can exchange security information directly  
without burdening C with it. This should be good enough to allow for  
cryptographically protecting the AS<->prefix mapping, for this  
particular feature it's not necessary that the security information  
and the routing information follow the same path. (Which is likely to  
be true for most mechanisms that are still "useful" with an  
unupgraded hop in the middle.)

But is this "discountiguous"? I think it's possible to argue either way.

It gets really interesting when you change this to:

A-B-C-D-E
   |   |
   SS  SS

where "SS" is a Security Server that imports AS<->prefix mappings and  
possibly other security information from the RIR databases etc. and  
injects it in our new secure inter-domain routing protocol.