Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle.

From: "Michel Py" <[email-masked]>
Date: Wed, 24 Jul 2002 22:02:19 -0700

Rpsec folk,

> Alex Zinin wrote:
> My opinion is securing the transport connection is not
> enough, and though particular protocol designers may choose
> to limit their security mechanisms to transport integrity
> and authentication, this WG should look further.

That would definitely suit my own needs as a protocol developer (I came
here for help).
To place things in context, let me make a few statements that apply to
my own views about protocol development, but might be applicable to
others:

- I am by no means a security expert (specifically, I do not know jack
about crypto). In my experience, developing a routing protocol requires
some expertise and experience with routing, and not that much with
security.

- Developing a routing protocol is all about one thing: compromises or
trade-offs. In that bigger picture, security is one out of 10 topics
that all have conflicting interests. A good routing protocol is not the
most secure, but the one that has a good balance between (non-exhaustive
list, in no specific order):

- Simplicity.
- Cost.
- Performance.
- Hardware/bandwidth requirements.
- Stability.
- Flexibility.
- Security.
- Ease of implementation.
- Optimality.
Etc..

WRT Alex's posting above, the choice that I would make about using
transport integrity and authentication (or not using it) is dictated by
many factors, that sometimes have very little to do with security.

WRT Steve's posting below, let me say very clearly that stating things
such as "if you have a problem with man-in-the-middle things, just use
IPSEC" or "let's not waste time documenting vulnerabilities issued from
unprotected transport mechanisms" are of no use to me. I don't know
IPSec, but I know enough about it to understand that the consequences on
the global balance of the routing protocol I am trying to design are so
bad that I can't use it.

In other words: my protocol (like many others) has a man-in-the-middle
vulnerability, and the reason I don't use IPSEC to solve it is because I
can't.

> Stephen Kent wrote:
> Over time I think the IETF has evolved to adopt a threat
> model that assumes man-in-the-middle attacks. We have some
> protocols that were designed with a more limited threat
> model, one that did not admit such attacks, and this has
> proven to be a mistake.

Allow me to say mostly the same thing, viewed from another angle. When
designing a routing protocol today, I have the general understanding of
the security issue that is the current state of it. In other words, I am
going to include in my protocol security mechanisms to dodge as many
attacks as possible.

Nevertheless, the bottom line still is: I'm doing my best, but it might
not be enough.

> If we assume that man-in-the-middle attacks are a
> valid concern,

I think we should.

> then the details of the underlying transport protocol
> probably do not matter much, since we will require a
> crypto-security mechanism to protect the traffic.
> It also is appropriate to document the ways in which a
> routing protocol relies on the underlying transport
> protocol. I don't think that documenting vulnerabilities
> of otherwise unprotected transport protocols is the best
> strategy for our work.

My problem is that the crypto-security mechanism that I could use to
protect the traffic does not exist. Until it is invented, I think that
it is appropriate to document the vulnerability, as correct operational
practices could reduce its scope; I do think that operational practices
recommendations or BCPs are definitely within the scope of this WG.

Michel.

http://arneill-py.sacramento.ca.us/ipv6mh/
http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt
http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Charles Lynn <[email-masked]>
Date: Thu, 25 Jul 2002 09:21:03 -0400 (EDT)

Hi Michel,

> I don't know IPSec, but I know enough about it to understand that the
> consequences on the global balance of the routing protocol I am trying
> to design are so bad that I can't use it.

[FWIW, the IPsec WG is revising RFC 2401 ...]

Can you explain why the current IPsec protocols are not able to
satisfy your needs, or why their use would make the protocol you
are designing not work well?

E.g., "needs too much bandwidth for the low bit rate radio links",
or "the protocol operates at the link-layer and IPsec is in the IP
layer".

Charlie

---

From: Alex Zinin <[email-masked]>
Date: Fri, 26 Jul 2002 22:35:01 -0700

Wednesday, July 24, 2002, 10:02:19 PM, Michel Py wrote:
...

> - Ease of implementation.

Very very true. And if this WG manages to reach a consensus on what
exactly this balance should be wrt security, we can say we
accomplished our goals.

BTW, the way I see the outcome from this WG as far as the requirements
(2nd step) are concerned is a document listing a bunch of :

  - MUSTs (things you gotta secure in your protocol),
  - SHOULDs (things you better have secured, but if you have a very
    good reason not to, beware of dragons),
  - MAYs (might be a good idea to look into this)
  - and probably SHOULD NOTs (things like bootstrap problems)

Alex