Thread (12 messages) 12 messages, 4 authors, 2009-05-05

Re: [RFC, PATCH 2.6.29.2] Ethernet V2.0 Configuration Testing Protocol, revision 20090428

From: Mark Smith <hidden>
Date: 2009-05-05 07:51:49

Hi Andi,

Thanks for your interest.

On Mon, 04 May 2009 11:29:55 +0200
Andi Kleen [off-list ref] wrote:
Mark Smith [off-list ref] writes:
quoted
+
+4. Security
+
+ECTP was designed in the early 1980s, when protocol security was less of
+a concern than it is now. Consequently, there are some features of the
+protocol which could be abused for nefarious purposes. By default, this
+implementation attempts to avoid participating in them. These features
+could be useful for some test cases thought, so they can be enabled if
+required.
I think security would need quite a bit more discussion. Opening new
DOS this way sounds quite worrying, especially since this is a
extremly obscure protocol that likely most admins don't know much
about.

Is this suspencible to ping to broadcast flood replication for example?
No it isn't. Forward addresses in forward messages (specifying the next
hop on the path) are prohibited by the protocol specification from
being multicast or broadcast addresses.
Safest would probably be default to off.
In my implementation, this unicast forward address check can't be
switched off.

Some of the other security mitigation mechanisms I've implemented
weren't really necessary, however I felt that it'd be good to ensure
this implementation was as good a "citizen" as possible.

Thanks,
Mark.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help