Subject: New DSR Draft

From: Yih-Chun Hu <[email-masked]>
Date: Fri, 22 Feb 2002 02:25:58 -0500 (EST)

We submitted our latest Internet-Draft (draft-ietf-manet-dsr-07.txt) 
today; we consider this to be a work-in-progress as we converge on a solid
document to send to the IESG. This draft can be found at
http://monarch.cs.rice.edu/internet-drafts/draft-ietf-manet-dsr-07.txt

The differences between -06 and -07 represent the major changes that have
been suggested as improvements to the draft. Though we invite comment on
this current iteration of the draft, but would like an opportunity to
further revise this document before the Last Call. 

Thanks,
Yih-Chun

---

From: Pekka Savola <[email-masked]>
Date: Sat, 23 Feb 2002 16:56:22 +0200 (EET)

> further revise this document before the Last Call. 

I read -06 a week ago because I'll have to write a paper about it in a
month or so.. and let's just say I didn't like what I read (everybody must
trust everybody 100%, changing IP to be a reliable protocol by
retransmissions, total incompatibility with anything like IPSEC,
piggybacking data and routing control, forcing every router to look into
DSR header killing "fast path" etc.); it seemed to be a nice piece of
academic work, "mental masturbation" some might say, but totally
unapplicable in any real use except, perhaps, for some very special cases
where the assumptions hold (perhaps some military networks).

But then again, this was a first manet draft I read, so perhaps all of 
them are more or less of the same.

I'll try to give more concrete feedback within some weeks but I'm not sure
if that's going to help any as the basic assumptions seem to vary quite a
bit.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Yih-Chun Hu <[email-masked]>
Date: Sat, 23 Feb 2002 14:53:39 -0500 (EST)

>trust everybody 100%, 

This is a given in manet. A number of groups are working on security right
now, but that is very much an area of research. Also consider how BGP is
implemented in the Internet today. Is that an unrealistic level of trust
as well?

>changing IP to be a reliable protocol by
>retransmissions, 

We're not trying to make IP reliable; the retransmissions are for the
purposes of neighbor detection. This is clarified in -07, where only the
neighbor reachability acknowledgements are retransmitted.

>total incompatibility with anything like IPSEC,

I don't see how it's completely incompatible with IPsec. Anything below
the DSR header can be encrypted or authenticated, in the same way as
Hop-By-Hop options in IPv6 are normalized before AH processing.

>piggybacking data and routing control, 

I fail to see how this is a problem. How is this different from, say, IPv6
Routing Headers?

>forcing every router to look into
>DSR header killing "fast path" etc

You're only checking the IP Protocol number for default flow forwarding
(dsrflow-00). Furthermore, if you need to run a manet routing protocol on
superfast links where you actually need fast path, you should seriously
consider RIP or DSDV; it's precisely those cases where you can just throw
bandwidth at the problem. Furthermore, all of manet by definition either
sacrifices fast path performance or kills scalability due to lack of
address aggregation, so mindlessly evaluating manet protocols from an
Internet routing requirements document isn't meaningful. 

>.); it seemed to be a nice piece of
>academic work, [...] but totally

If you don't believe the assumptions, perhaps other IETF working groups in
the routing area would interest you more. Most of the people actively
working in the manet WG would strongly disagree with you on this point,
and in each of our research papers on the area, we stress the scenarios
where ad hoc networks may be applicable. Our papers can be found at:
	http://monarch.cs.rice.edu/papers.html

---

From: [email-masked]
Date: Sat, 23 Feb 2002 17:00:51 -0500 (EST)

Hi,

> implemented in the Internet today. Is that an unrealistic level of trust

In order to implement Secure Routing, there is *no* need for full
trust relations among the nodes (i.e., no everyone has to trust
everyone else).

For more inofrmation, see the Secure Routing Protocol (SRP):

P.Papadimitratos and Z.J. Haas, "Secure Routing for Mobile Ad Hoc
Networks,"  SCS Communication Networks and Distributed Systems Modeling
and Simulation Conference (CNDS 2002), San Antonio, TX, January 27-31,
2002.

You can download it from our WNL web page.

Enjoy!

Zygmunt.
==-=-====
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Prof. Zygmunt J. Haas                    http://people.ece.cornell.edu/haas 
Wireless Networks Laboratory		 http://wnl.ece.cornell.edu
School of Electrical Engineering         
Cornell University			 tel: +1-607-255-3454
323 Frank Rhodes Hall			 fax: +1-607-255-9072
Ithaca, NY 14853			 e-mail: [email-masked]
U.S.A                             
	WNL web page: http://wnl.ece.cornell.edu
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Feb 2002 00:45:49 +0200 (EET)

I had wanted to avoid further comments for a few weeks, but I'll comment 
on a few issues.

> Hop-By-Hop options in IPv6 are normalized before AH processing.

Source/destination addresses are usually included in IPSEC ICV
calculations, and AFAIR these can change in transit (I recall some oddness 
with 255.255.255.255 at least, but not sure).

By the way, have you considered whether wide-scale use of 255.255.255.255 
is a good idea?  If it's supposed to work off-link, I sense a new 
directed-broadcast -style attack wave coming (using routing header as a 
reflector from the remote router).
 
> I fail to see how this is a problem. How is this different from, say, IPv6

Routing Headers aren't significantly overwritten in the process of being
transferred around the network.  AFAIR, whole DSR options can be removed
or added while in transit.

Note that if above is true, this could be rather problematic from Path MTU 
discovery perspective.

There are some issues with routing headers, by the way, especially in 
production networks:

http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt

most of these don't probably apply to the DSR scenario.
 
> Internet routing requirements document isn't meaningful. 

Another, related problem: all routers must support DSR, else they can't
dig into DSR header's options and see if they should process the header.
(as the router is not the destination address of the packets.)
 
> If you don't believe the assumptions, 

For example, you refer to 802.11 as a potential technique, rely solely on 
the security of the link-layer, but we all know that for practical 
purposes there exists none in 802.11.

---

From: [email-masked]
Date: Sat, 23 Feb 2002 17:45:00 -0500 (EST)

> By no means do I intend to belittle recent progress in the area of
> practical, secure routing mechanisms for ad hoc networks; I'm only
> pointing out that _none_ of the current manet WG IDs do an acceptable job
> of providing security, and that for some time to come (at least a year or
> two) none of the proposed secure protocols make sense as Experimental
> RFCs. 

Hmmm, to backup such a strong claim, you would need to show that there
is a substantial flaw in *every* secure routing mechanisms proposed there.
This might be tough call ....

I agree with you that various of those schemes have different assumptions-
some more realistic than others. (For instance, as opposed to other
works, our scheme has the salient features that it does not require
security binding between *intermediate* nodes; only between the "source"
and the "destination".) But even if some of the assumptions in some
schemes (others, not ours (:-)), make less than realistic assumption, I
feel that your statement that "none_ of the current manet WG IDs do an
acceptable job of providing security" is a bit too harsh. Wouldn't you
agree?

Zygmunt.
==--=-==-==

> Also,
> Radia Perlman. Network Layer Protocols with Byzantine Robustness.
> Technical Report, MIT Laboratory for Computer Science #429, October 1988.
> 
> Manel Guerrero Zapata. Secure Ad hoc On-Demand Distance Vector (SAODV)
> Routing. IETF MANET Mailing List, Message-ID: 
> [email-masked], URL: 
> ftp://manet.itd.nrl.navy.mil/pub/manet/2001-10.mail, October 8, 2001. 
> 
> Bridget Dahill, Brian Neil Levine, Elizabeth Royer, and Clay Shields. A
> Secure Routing Protocol for Ad Hoc Networks, Technical
> Report UM-CS-2001-037, University of Michigan, August 2001.
> 
> Seung Yi, Prasad Naldurg and Robin Kravets. Security-Aware Ad hoc Routing
> for Wireless Networks. Technical Report UIUCDCS-R-2001-2241, UIUC, August
> 2001.
> 
> My point is that none of these papers have been out long enough or
> publicized well enough or independantly tested using simulation and
> implementation to be a serious candidate within manet at the present time. 
> Furthermore, no single manet-wide threat model has ever been defined, so
> if you adopt the no node compromise model, MAC layer encryption with
> integrity is sufficient, and if you assume no single trusted entity, you
> need a PGP-style web-of-trust for certificates.
> 
> By no means do I intend to belittle recent progress in the area of
> practical, secure routing mechanisms for ad hoc networks; I'm only
> pointing out that _none_ of the current manet WG IDs do an acceptable job
> of providing security, and that for some time to come (at least a year or
> two) none of the proposed secure protocols make sense as Experimental
> RFCs. 
> 
> Yih-Chun
>

---

From: Yih-Chun Hu <[email-masked]>
Date: Sat, 23 Feb 2002 17:36:25 -0500 (EST)

Also,

Yih-Chun

---

From: Yih-Chun Hu <[email-masked]>
Date: Sat, 23 Feb 2002 18:07:40 -0500 (EST)

>with 255.255.255.255 at least, but not sure).

Nope. DSR doesn't change these in transit (or if it does, for route
request piggyback, it'll change them back before delivery to IP).

>reflector from the remote router).

That's filterable. A good point, though, for the (I think several) groups
here working on internet bridging. In any case, manet has considered a
1-hop all manet nodes multicast address. I don't know the status of that.
If it's there, we should use it. If not, maybe we should make one.

>or added while in transit.

Entire options, yes, but generally the header will stay intact. In almost
all cases, any options will stick around. A few (ie acknowledgement) are
hop-by-hop, but they're rarely used in typical networks (MACA/MACAW style
MAC, bidirectional, ...).  IPv6 Source Route headers have addresses
swapped around inside, so that's some amount of change. I'm wondering if
there's any practical difference between (occasional) substantial change
and consistant "slight" change.

>Note that if above is true, this could be rather problematic from Path MTU 

Understood. But there are standard tricks that can be played with Path MTU
discovery. And as long as a single route is being used, Path MTU works
just fine. Just as in the Real World, when the route changes, the MTU
might as well.

>(as the router is not the destination address of the packets.)

(This is another point I spoke too quickly on. AODV provides some level
of address aggregation, but the protocol as currently specified doesn't
provide dynamic aggregation. As a result, nodes within an aggregated route
record must be routable from the replier.)

Yes, all routers must support DSR. Just like all Internet gateway routers
must support BGP. Most routing protocols work this way, right?

>purposes there exists none in 802.11.

Yes, yes, 802.11 has woeful security problems. Even if you addressed
issues like WEP, DOS attacks are trivial. Link-layer encryption should be
"correctly" implemented at some point; otherwise, several, less-reviewed,
incompatible layers could be added to 
	{DSR,AODV,TBRPF,OLSR,FSR,IERP,IARP,BRP,LANMAR}, 
or we could all agree on a manet-wide security shim. Not that I'm at all
biased about which solution I prefer ;) 

Yih-Chun

---

From: Yih-Chun Hu <[email-masked]>
Date: Sat, 23 Feb 2002 18:50:16 -0500 (EST)

>This might be tough call ....

No, I'm saying that it'll take a year for any of these protocols to mature
and be well-enough cooked for WG consensus on publication as an
Experimental RFC. The sense of time referred to the RFC, not to the work.

>and the "destination".) 

I generally agree that that's a good assumption. Having certificates for
all nodes may be reasonable as well, and the you can use those certs to
set up a security association on-demand. Your earlier work with multiple
CAs, however, may be a more conservative assumption, and the
military-types may like that, instead.

>But even if some of the assumptions in some

The current manet WG IDs
(http://www.ietf.org/html.charters/manet-charter.html) 
are:

http://www.ietf.org/internet-drafts/draft-ietf-manet-aodv-10.txt
  which says "Currently, AODV does not specify any special security
  measures"
http://www.ietf.org/internet-drafts/draft-ietf-manet-tora-spec-04.txt
  which says "TBD" under Security Considerations
http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-07.txt
  the draft that sparked this... discussion
http://www.ietf.org/internet-drafts/draft-ietf-manet-olsr-05.txt
  which has no security considerations section
http://www.ietf.org/internet-drafts/draft-ietf-manet-tbrpf-04.txt
  which vaguely alludes to using IPsec to cover all evil
http://www.ietf.org/internet-drafts/draft-ietf-manet-lanmar-03.txt
  which has no security considerations section
http://www.ietf.org/internet-drafts/draft-ietf-manet-simple-mbcast-01.txt
  the same cop out as the DSR draft
http://www.ietf.org/internet-drafts/draft-ietf-manet-fsr-02.txt
  which has no security considerations section
http://www.ietf.org/internet-drafts/draft-ietf-manet-zone-ierp-01.txt
  which has no security considerations section
http://www.ietf.org/internet-drafts/draft-ietf-manet-zone-iarp-01.txt
  which has no security considerations section
http://www.ietf.org/internet-drafts/draft-ietf-manet-zone-brp-01.txt
  which has no security considerations section
http://www.ietf.org/internet-drafts/draft-ietf-manet-dsrflow-00.txt
  the same cop out as the DSR draft
http://www.ietf.org/internet-drafts/draft-ietf-manet-bcast-00.txt
  "It does not make any provision for securing the contents of the flooded
   data, either to protect against tampering or to protect against
   unauthorized inspection of the data."

Which one of these provides acceptable security?

I'm not trying to downplay anyone's work in secure routing, or in general
ad hoc network routing. It's very possible that your work or any of the
other group's work could provide acceptable security in a number of
environments. I'm just (rather bluntly) stating that this is a young and
not very well understood area. There is good work in this area, and work
is progressing, but to say that the community at large has confidence in
any one protocol would be premature.

Yih-Chun