Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02

From: Vishwas Manral <[email-masked]>
Date: Tue, 29 Mar 2005 20:58:10 -0800

Hi Acee,

> The side effect of recommending to ignore unknowns is creation of the
> impression that we can rely on this behavior when defining new link
types, 
> while in fact we can't. And if we can't rely on it, then why specify?
I may be totally off target, however stating that a solution to a
problem should not be accepted because it will not be immediately
effective may not be right. I think stating it will get the behavior in
all major/ new and highly used implementations soon if not immediately.

As I pointed out in my previous mail, malicious packets can very well be
sent if we know this creates routing problems (and other interesting
problems that Dave mentioned) and we will never have a solution to that
if we leave things open-ended.

Thanks,
Vishwas
-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Alex
Zinin
Sent: Wednesday, March 30, 2005 9:19 AM
To: [email-masked]
Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02

Acee,

> And I believe we agree that isn't desirable to handle the addition of
all
> possible future link types in this draft since due to simply fact that
> different link types may require different compatibility
considerations.

Right.

> At least defining the rules would provide a migration path if vendors
and open
> source developers follow the rules.

Even if everyone on this list jumps on it tomorrow and checks their code
to
ensure the follow this recommendation, there will still be networks out
there
that happily run old equipment with old SW from vendors that don't even
exist
anymore.

The side effect of recommending to ignore unknowns is creation of the
impression
that we can rely on this behavior when defining new link types, while in
fact we
can't. And if we can't rely on it, then why specify?

From your message to Dave:
> In a perfect world, an OSPF routing domain is under a single
administrative
> authority and that authority should have some control over what is
deployed.

This is a reasonable assumption. On the other hand, it seems we
shouldn't assume
that the administrator of a moderate enterprise network knows all
details of the
protocol machinery to the details of how version X of a specific
implementations
handles this scenario. Since there would be no protocol-level safeguards
against
newer implementations conflicting with legacy ones, it would look very
shaky.

> If we can't agree that this is a good thing to do then I guess the
default
> action is to maintain the status quo of leaving it undefined. At least
> initially, the concensus was to ignore the unknown link types.

It's a good thing we're having this discussion early in the process.

Alex

---

From: Dave Katz <[email-masked]>
Date: Wed, 30 Mar 2005 08:23:45 -0700

> if we leave things open-ended.

Sorry, you're way off base here.  If somebody wants to send malicious 
packets into an OSPF network, there are an infinite number of ways of 
breaking things, and this change leaves (infinity - 1) of them.  The 
*only* way to protect against this is cryptographic authentication.

Similarly, there are an infinite number of ways for a benign but broken 
implementation to break things, and this doesn't fix those either.

The only argument for this is as a way to possibly avoid future 
extension problems, but I don't think it helps there either.

--Dave