RE: [DNA] QUESTION: Remove Link Down information indraft-ietf-dna-link-information-03

[Michael Williams <Michael.G.Williams@nokia.com>]

Is it possible there is too much value being placed on the link indications.. i.e. the mitigation of risk being requested here goes beyond the value of the 'asset'? We've lived with relatively weak routing protocol mitigation for some time. Although that may need to change, the link indications are significantly less risky aren't they? 
The initial concern about link indications was about reliability of the eaning of the hint.  

> -----Original Message-----
> From: owner-dna@ecselists.eng.monash.edu.au on behalf of ext Alper Yegin
> Received: Fri Jul 21 04:30:03 EEST 2006
> To: 'Bernard Aboba'
> Cc: 'James Kempf', suresh.krishnan@ericsson.com, 'Dna', 'greg Daley', 'Jari Arkko (JO/LMF)'
> Subject: RE: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03
> 
> I think this is a different problem than what we've been discussing so far.
> The former issue was "spoofed indications due to lack of message
> authentication." Now what you are talking about is "spoofed indications due
> to misbehavior of authentic peers."
> 
> Dealing with the latter is a *lot* harder problem, which I don't think we
> want to deal in DNA WG. (well, probably you are not suggesting that
> anyways).
> 
> Alper
> 
> 
> 
> 
> > -----Original Message-----
> > From: Bernard Aboba [mailto:aboba@internaut.com]
> > Sent: Wednesday, July 19, 2006 7:16 PM
> > To: Alper Yegin
> > Cc: 'James Kempf'; suresh.krishnan@ericsson.com; 'Dna'; 'greg Daley';
> > 'Jari Arkko (JO/LMF)'
> > Subject: RE: [DNA] QUESTION: Remove Link Down information in draft-ietf-
> > dna-link-information-03
> > 
> > > I believe that one could reasonably conclude the problem can't be
> > > solved, barring some fundamental change in network to host signaling
> > > security. Am I missing something here?
> > 
> > I'd observe that the transmission of remoted link status
> > indications (including but not limited to "link down")  is in principle no
> > different from transmission of Link Status Advertisements (LSAs)
> > within a routing protocol.
> > 
> > The question is how the LSAs are secured.  Just as transmission layer
> > security may not be enough when dealing with injection of faulty
> > prefixes by trusted parties (think BGP peers using IPsec or TCP MD5 to
> > protect the session), there are issues that go beyond whether the remoted
> > link status message is secured or not.  For example, even if the message
> > were to be signed by the sending router (e.g. via SEND), there would still
> > be the question about whether the sending router was actually on the path
> > or not.
> > 
> > So yes, the problem is hard, but it is more or less the same problem as
> > routing protocol security (which is hard).
> 
> 
> 
>