Subject: [SAVA] Some thoughts on the direction(s) SAVA should take...

From: fergdawg at netzero.net (Fergie)
Date: Thu, 10 May 2007 01:46:11 GMT

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070510/85617cac/attachment.txt

---

From: miaofy at huawei.com (Miao Fuyou)
Date: Thu, 10 May 2007 12:14:49 +0800

> Which is why I think that whatever work is brought to the 
> IETF (if it is brought into the IETF) needs to be somewhat 
> compartmentalized, given defined deliverables & milestones, 
> such that the architecture lends it self to various sorts of 
> locally implemented _mechanism_, but a commonly defined and 
> implemented end-to-end transitive implementation.
> 
> So, what I propose is to break SAVA work items into 
> _at_least_ two parts: local subnet/first-hop source address 
> validation, and secondly, how to communicate that this has 
> been done upstream.

I like this compartmentalization, it clearly shows the primary (but,
functionally quite different) parts of SAVA: validation and end-to-end
transition of trust. There are quite some mechanisms for subnet/first hop
source address validation, such as BCP38 and MAC/IP/Line binding checking.
Probably there will be some more BCP documents on how to first hop address
checking, however, I believe the major work for these group would be in
end-to-end transition of trust part. 

Miao

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 10 May 2007 08:09:49 +0300 (EEST)

Hi,

I agree with almost all you write so I won't quote it, but there are 
some minor differences further down..

On Thu, 10 May 2007, Fergie wrote:
> [...]
> The real issues here is to describe what "SAVA validation" really
> means, and what the desired result is within any particular locally
> administered domain ("You must be at least 'this tall' to claim to
> be 'SAVA Compliant'"), and then figure out how to communicate this
> in a transitive nature from end-to-end such that any "SAVA Compliant"
> or "SAVA Validated" prefixes can be recognized [...]

The first question I'd ask here, is the IETF the right place to 
specify what constitutes 'SAVA compliancy'?

Maybe we could have a BCP on this, but to me this choice of venue is 
not obvious.

At least, I suspect this shouldn't done until the mechanisms such a 
BCP refers to have been sufficiently deployed so that there is real 
experience on using them.

I'll note that if the mechanisms available to the network operators 
are good enough (which probably means: better than they're today), 
benefits might come automatically as a result of the mechanisms being 
available, and I don't see that such a BCP is necessarily needed.

> Which is why I think that whatever work is brought to the IETF (if
> it is brought into the IETF) needs to be somewhat compartmentalized,
> given defined deliverables & milestones, such that the architecture
> lends it self to various sorts of locally implemented _mechanism_, but
> a commonly defined and implemented end-to-end transitive
> implementation.
>
> So, what I propose is to break SAVA work items into _at_least_
> two parts: local subnet/first-hop source address validation, and
> secondly, how to communicate that this has been done upstream.

Yes, I agree that the work needs to be split.  I'd say we'd need to 
look at more than two parts but until there's more detail that's fine.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings