[Chapter-delegates] Net Stability

[Franck Martin]

chapter-delegates at elists.isoc.org wrote:

>Narelle Clark wrote:
>  
>
>>http://www.lightbluetouchpaper.org/2006/04/07/when-firmware-attacks-ddos
>>-by-d-link
>>
>>I recall seeing this before:
>>http://www.cs.wisc.edu/~plonka/netgear-sntp/ gives a really lengthy
>>account of other manufacturers and what befell the Australian national
>>NTP server. I recall that had to be blocked at the carrier/IAP level.
>>  
>>    
>>
>Dear Narelle,
>
>While I agree with you, this has nothing to do with RFC compliance, but
>rather with an impolite behaviour and a bad implementation on the side
>of Netgear and Dlink..
>  
>
unless this become part of a RFC ;)

>>Certifying Internet appliance and software?
>>
>>A darn good idea. 
>>Start at the latest RFC# and work backwards... There's a massive amount
>>of non compliance! With some services/systems being more detrimental
>>than others.
>>    
>>
>What compliance ? A practical example.One could most probably certify
>Sendmail/Postfix/Exim, etc as being RFC compliant. But if the
>implementation on my local system allows pre-greeting traffic, it breaks
>RFC2821. But OK, I could tell my boss that I cannot be blamed, since I
>am using a certified RFC compliant MTA.
>  
>
It is not because a piece of hardware is certified microsoft compatible 
that it won't crash. Same in security, I think linux has been certified 
C2, which means you can implement it and get it C2 certified. I guess it 
would be the same in this case, a software would be deem certified if a 
specific implementation can be fully compatible with an RFC.

I buy pieces of hardware that say compliant RFC this and RFC that on 
their boxes, but how do I know?

Does the IEEE has a certification process?

>As for starting with the latest RFCs, I have mixed feelings. The latest
>ones may not be implemented yet. There are older and critical services
>like SMTP and DNS where non-compliance is common (mostly because of
>lousy admins) that need to be addressed first, IMHO. Rather than
>certifying software, we should try to certify people or groups of people
>(ie companies).
>  
>
Not all RFC would be included but I guess it would be a stream of RFCs, 
the most common ones. Recently I found out that ekiga.org and 
asterisk.org were not following a SIP RFC, where their implementation 
should have been a SHOULD they made it a MUST. Result, in some 
situations the audio is lost.

However, I would also be careful about a full certification process, as 
it would not allow FOSS to be certified. Who would pay for the 
certification?

Sure this idea needs to be massaged a little bit, get the pros and cons 
and see where we go...

What I do like is the www.rfc-ignorant.org filtering list, which lists 
mail servers which do not respect RFCs. May be ISOC could support it?

In terms of e-mail, what we are missing is the support of big companies 
like Google, Yahoo, Hotmail. If they implement some standard filtering 
rules rejecting e-mails, then suddenly all mail systems in the world 
would start to comply, but then if one does it alone, it would loose its 
customers to other mailers that are not that strict. Here ISOC could 
provide the brokering environment to make them all sit at the table and 
agree to some standards.

As a first step, may be look at www.rfc-ignorant.org procedures if they 
seem serious and then ISOC advocating to the big mailer service to use 
it, and the chapters to their local ISPs?

Cheers.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Franck Martin
franck at sopac.org
"Toute connaissance est une réponse à une question"
G. Bachelard