Subject: [Hipsec] MAST: A perhaps simpler alternativity to HIP?

From: [email-masked] (Dave Crocker)
Date: Sat Aug 30 00:12:01 2003

First, I need to apologize.  I missed the mailing list transition, so my
original attempt to copy the announcement to the list failed, yesterday.

Second, thanks to Pekka for posting it.

As to technical matters:

> If this is what I think it is, it is equivelant to a HI that is not
> cryptographic.  With all the warnings the HIP architecture has about such 
> an approach.

My feeling is that it is essential to have adequate security, but it is
equally essential to be clear what that means, in this case.  My view is
that adequate security means protection against spoofing, on a par with
the protection that is present for a regular TCP connection.  Hence,
there needs to be very strong protection against falsely inserting a new
address into the working set for an association.  But there does not
need to be any other security, since none is present in a regular TCP
connection.

SCTP's mechanism is probably fine, but my reaction to DCCP's equivalent
mechanism was that it is stronger.  I have no religion on this point and
frankly can't do more than an amateur's job of designing it myself.
That's why I was delighted to see the SCTP and DCCP mechanism.  I had
originally felt compelled to use BEEP and SASL for this, which is gross
overkill.

That said, I've no doubt the details of the security design need to be better.

> - it makes a different choice with respect to NAT handling--
> HIT effectively substitutes IPsec protection for transport
> checksums.  MAST tries to keep use of transport checksum.
> The difficulty in this approach is that MAST must then
> know at the end system how a NAT may transform its IP
> addresses and port numbers.  It proposes a PROBE message for this. =20
> If the addresses learned by the PROBE reliably map to the addresses
> that the NAT will use for a subsequent TCP segment, then it=20
> probably can work, although I am not sure that all NATs will=20
> transform the PROBE and the subsequent TCP segment to the same
> port number.

mumble...  good point...  grrr...

yes, I had been thinking that a NAT would behave the same for a stray
protocol, like MAST, as it does for TCP.  As you point out, it might
not, though I'm wondering what the choices are.

Either a NAT works for arbitrary programs or it only works for a (tiny)
few. The odds that a NAT will use highly varied schemes for random
protocols seems unlikely to me. Tailored behavior for special, known
protocols, like FTP, is one thing. Varied behavior for random protocols
is another.

Does anyone have direct knowledge about this?

d/

/d
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>