At 10:26 PM -0700 12/13/01, Alex Zinin wrote:
> >> A router must be able to detect, and should be able to recover
>from transitive
>>> data inconsistencies. Good, valid data from 1 or more sources must not
>>> be combined together with existing or received data to create a
>>>destabilizing
>>> effect(for some value of destabilizing) . If a router is not able
>>>to recover, it
>>> must not propagate the inconsitent data if the router is a
>>>propagator of control
>>> information.
>
>> This came up in the context of the current ambiguities in the
>> BGP confederatins spec.
>
>> A syntactially correct packet, i.e. a packet that is well-formed,
>> should not be the reason to tear down a peering session. If the
>> packet is syntactically correct, but some portion of it is semantically
>> incorrect, it should be received, ignored, logged and not propagated.
>
>Jeff,
>
>Thanks for the note.
>I think it should be formulated explicitly in terms of
>syntactic and semantic correctness, as you put it above.
>Definition of "good" and "valid" is kind of vague.
>
>Furthermore, I think this requirement should be extended
>to say that not just a router, but the system should
>be able to handle this correctly.
>
>Alex.
While I always hesitate to cite something ISO-ish, there is
terminology in the ISO 9646 conformance testing methodology that
might serve as a _starting_ point for explicit formulation.
9646 defines three kinds of test cases:
1. Correct, where the PDU is completely appropriate but may test boundary
conditions within the specification,
2. Incorrect, where there are syntactical errors, possibly of a type that
a PDU can be partially decoded,
3. Inopportune, which could be better defined. In general, it appears to
refer to the behavior caused by the reception of a PDU not relevant to
the current state of the receiver (e.g., a BGP speaker receiving an
UPDATE before the peering is established).
Depending on how one defines "state," I think the inopportune case is
a starting point for what is being called semantic correctness. Other
things that might fall under semantic incorrectness include:
1. Reception of information dependent on a negotiable capability that
was refused during capability establishment
2. Martian/bogon addressing and the like
This taxonomy really doesn't have a place for such things as sanity
checking (e.g., BGP prefix limit) or DoS detection. But it's a start.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT