What you described is BCP38. OK. Done. Everything else are techniques/features/functions to implement BCP38. We know that BCP38 works. We've got a lot of experience with it and there has been a lot of innovation to enhance BCP38 (BCP38 ++) so that you "know" the source address came from an authorized source (i.e. in the world of Cable and ETTX/Metro/Carrier Ethernet).
So back what is the point of Sava? I'm not seeing anything new? Pekka's worked on an BCP 38 experiences docs. RIPE is working on a BCP38 config guide. > -----Original Message----- > From: Ron Bonica [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 14, 2006 1:07 PM > To: Pekka Savola > Cc: Jun Bi; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [SAVA] Re: [Int-area] Call For Participation and > Interest: Source Address Validation Architecture (SAVA) > > Pekka, > > You raise some very fundamental questions about SAVA. I will > try to enumerate and answer them. If I get any of the answers > wrong, I invite the SAVA contributors to step up and correct me. > > First, you ask what it means for a packet to have a "valid > source address". It means that there is some degree of > certainty that the packet originated at a site to which the > address was assigned by a legitimate numbering authority. > This is a much stronger statement than an alternative > definition, which claims only that the packet is not spoofing > some well known address (for example, one of your own > backbone addresses). > > The degree of certainty that source address filtering and > uRPF can provide is inversely proportional to the number of > hops between the validating and originating devices. So, > (although this might be anticipating solutions), the SAVA > architecture will probably include a source address > filtering/uRPF component that will be implemented by upstream > routers, and a signature component, by which the upstream > router notifies downstream routers that validation has (or > has not) occurred. > > Next, you ask what network resource are protected by SAVA. I > think that the answer is the entire Internet, but especially > the routers that are close to the validating nodes. This is > because SAVA can identify all of the following classes of > spoofed packets: > > a) spoofed packets that are bound for routers (in the local > or remote AS) > b) spoofed packets that are bound for hosts, but cause router > interfaces to congest. > > Ron > > > > > _______________________________________________ > routing-discussion mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
