Subject: RE: [DNA] QUESTION: Remove Link Down information in draft-ietf-dna-link-information-03

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Jul 2006 23:18:54 -0700

> > are L2 technologies and architectures that can secure link up but not
> link
> > down? Otherwise link up would be as harmful as link down is.
> 
> Perhaps this is referring to the ability to spoof management traffic that
> can result in a "Link Down" indication?  For example, in 802.11 the 4-way
> handshake is secured, but management traffic such as Disassociate,
> Deauthnticate, etc. are not (this is fixed in 802.11w).  So "Link Up" is
> not spoofable (at least in 802.11i) but "Link Down" is.
> 
> On the other hand, a microwave oven, or large scissors will also do the
> trick for many links ;)

Yes, this is a good example. But are there enough many other examples to say
"nobody has ever figured out a way to allow it (link down) to be done
securely."?

Btw, this does not say "link down is harmful" to me. It says there are
technologies whose link can be brought down by attackers. Whether a link is
brought down legitimately or maliciously, it is down as far as the L2 and L3
are concerned. 

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 19 Jul 2006 15:15:48 -0700

Jim,

I think we shall pinpoint where the "fundamental problem" is.

I don't think the fundamental problem is with the "link down" when it comes
to spoofing. When such threat is possible, the fundamental problem is with
the specific L2 design that does not allow signing (authenticating) L2
management signaling that leads to link down. And that applies to any other
L2 management signal that is not signed - link *.

If someone wants to write a document "not signing L2 management signaling
for wireless networks is considered harmful", that's fine. But than, that's
very obvious.

Alper

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 12:43 PM
> To: Alper Yegin; 'Bernard Aboba'
> Cc: [email-masked]; 'Dna'; 'greg Daley'; 'Jari Arkko
> (JO/LMF)'
> Subject: Re: [DNA] QUESTION: Remove Link Down information in draft-ietf-
> dna-link-information-03
> 
> Alper,
> 
> "Is harmful" is typically a title for an RFC that discusses concerns about
> some topic. As Bernard says, the problem is that, at the IP level, it is
> possible to spoof "Link Down" traffic As you say, it is possible that some
> L2 protocol could provide a secure way to indicate "Link Down". My point
> was
> that the topic of IP level "Link Down" has been discussed now in one WG
> (DNA) and one BOF (TRIGTRAN) and also I think in another BOF over the last
> few years., and the conclusions have been the same  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?
> 
>             jak
> 
> ----- Original Message -----
> From: "Alper Yegin" <[email-masked]>
> To: "'Bernard Aboba'" <[email-masked]>
> Cc: "'James Kempf'" <[email-masked]>;
> <[email-masked]>; "'Dna'" <[email-masked]>; "'greg
> Daley'" <[email-masked]>; "'Jari Arkko (JO/LMF)'"
> <[email-masked]>
> Sent: Tuesday, July 18, 2006 11:18 PM
> Subject: RE: [DNA] QUESTION: Remove Link Down information in
> draft-ietf-dna-link-information-03
> 
> 
> > brought down legitimately or maliciously, it is down as far as the L2
> and
> > L3
> > are concerned.
> >
> >
> > Alper
> >
> >
> >
>

---

From: Michael Williams <[email-masked]>
Date: Fri, 21 Jul 2006 09:42:25 +0300 (EEST)

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.  

> From: [email-masked] on behalf of ext Alper Yegin
> Received: Fri Jul 21 04:30:03 EEST 2006
> To: 'Bernard Aboba'
> Cc: 'James Kempf', [email-masked], '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
> 
> 
> 
> 
> > From: Bernard Aboba [mailto:[email-masked]]
> > Sent: Wednesday, July 19, 2006 7:16 PM
> > To: Alper Yegin
> > Cc: 'James Kempf'; [email-masked]; '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).
> 
> 
> 
>