[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bandwidth reservation and AH, and non-MD5 based AH.



In a galaxy far, far away, : Mon, 05 Feb 1996 23:49:31 PST
> If AH with a symmetrically-keyed MAC is used just for protecting reserved
> bandwidth (not for secure end-to-end source authentication or message
> integrity), then it doesn't seem like such a big deal to have to trust a
> few routers to hold your bandwidth session-key.

  I agree. It doesn't sound that bad. But, which routers do I share the
secret with? My packet could go via different routes each time. The routers
could be "owned" by malevolent entities.
  How do I negotiate the AH key for the RSVP differently from the one I use
for authentication?
  I'd like to use RSVP on *all* my data. It seems like an ideal way to
cope with many denial of service attacks. 
  RSVP specifies that the recipient sets up the reservations. IPsec does
a similar thing: the receiver picks the SPI. So in any public key system, the 
recipient has to let the router know what public key is going to be signing 
which SPI. I have to review RSVP again to figure out how that works... 
(RSVP does provide for having AH protected RSVP messages. But it also
provides its own encryption facilities. I think it should stick to AH)

> (After all, you have to trust them to actually give you the bandwidth which
> they've promised to reserve for you.)

  Yes, then the question arises: how close to the backbone do I have to reserve
bandwidth for? Do I let other people reserve bandwidth for their data
to leave my domain of physical control over my 56k link? 

> Yeah, that's a problem with public-key stuff: it's so slow.  Do note that
> signature verification is much faster than signature generation when you use
> RSA with a small public exponent, though it is admittedly still quite slow.

  Yes, I've read that paper.

  




References: