Subject: RE: questions on INFORM draft

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 20 Aug 2002 10:44:01 -0400

> 
> On Sat, Aug 17, 2002 at 02:58:52PM -0400, Avi Freedman wrote:
> > That said, I will go back and recheck the behavior of various
> > routers for reserved ASs appearing outside confederation segments.
> > Perhaps that's not an issue any more.
> 
> That would be appreciated.
> It may even be worthy of an ID - or at least something for the
> museum of broken packets.
> 
> > I think we might be agreeing - I'm not suggesting that fixing broken
> > packets is the desired thing, but rather that not requiring that
> > one broken packet being propagated take down a peering session is
> > the desired thing.
> 
> Here is the trick:
> When I receive a packet that is either well- or mal-formed
> that wasn't originated by the adjacent router, how can I tell that
> the information is the individual fields is mostly correct?
>

TCP will check the header and data fields of a packet for correctness as
its associated checksum when calculated will identify any data corruption. 
If the sending BGP peer puts malformed/bad NLRI information in the packet
the TCP layer will not catch it. If the receiving BGP peer determines that
the NLRI is invalid, it should have a way to say something is wrong with the
given packet and maybe send it back as an attached data portion to an INFORM
message. If the offending peer continues to send malformed/bad NLRI packets,
the receiving peer should drop the session. I would think that is a
reasonable
way to handle malformed/bad NLRI packets.

Ben

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 Aug 2002 11:50:54 -0400

> its associated checksum when calculated will identify any data corruption. 

Its the BGP PDU I'm concerned with.
The most common BGP errors have to do with forming a bad packet.

> If the receiving BGP peer determines that
> message.

If we have determined that some portion of the packet is bad - say
the route origin (e.g. type=4), can we trust the rest of the packet?

If we trust the NLRI is correct and well formed, we could then 
delete those NLRI as being "bad" from our adj-ribs-in for that peer.

If we can't trust them, all we can know is we're out of sync with that
peer.  We may have to mistrust up to a full-packet's worth of
routes - but which ones?

-- 
Jeff Haas 
NextHop Technologies