Subject: RE: [Fwd: [mobile-ip] Mobile IPv6 clarifications]

From: Phil Roberts <[email-masked]>
Date: Tue, 24 Jul 2001 13:35:18 -0400

> Note that even with this issue resolved, you still have to deal with
> the PKI/authentication/etc. issues involved with SA setup; if
> anything, this is a much harder problem..
> 
> 					- Bill
> 

Right.  And the perspective has been, I believe, to solve the harder problem
before determining how the protocol supports it.

---

From: Phil Roberts <[email-masked]>
Date: Fri, 27 Jul 2001 14:54:49 -0400

Hi Bill,

    I appreciate your comments and welcome your involvement.  But I'd like
to
repeat that we've been saying it's premature to determine specific changes
to
make to the protocol.  We've just published a security requirements draft
which
we're still waiting for significant feedback on.  Until we have some sense
of
what needs to stay there and what is superfluous it's hard to make a
determination
about what needs to be done.  It's probably not unfair to say that a lot of
work has been done on this protocol and a lot of design decisions have been
around
for some time.  There is plenty of sweat shed in implementation.  That is
not to
say that if something doesn't work it won't be fixed, it has to, but it is
to say that people would prefer to do so without significant changes.

Phil

> -----Original Message-----
> From: Bill Sommerfeld [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 3:36 PM
> To: [email-masked]
> Cc: Alexis; Phil Roberts; Basavaraj Patil (NTC/Dallas); Abha Ahuja;
> Thomas Narten; Dave Johnson; Jeff Schiller; Marcus Leech; 
> Pekka Nikander
> Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications] 
> 
> 
> > I think you two are actually in violent agreement, as I read Vijay's
> > comment as meaning that killing piggybacking in the spec if that
> > were necessary wouldn't be any huge loss.
> 
> I didn't read his comment that way.
> 
> Oh, by the way...
> 
> Once you've thrown out piggybacking, why not also throw out the whole
> binding-update, home-address, etc., etc, option scheme and just go to
> a much simpler ipvN-in-ipvN tunneling scheme in conjunction with a
> tunnel setup/update protocol?  Yes, the packets get slightly bigger,
> but header compression can deal with that over low bit-rate links.
> 
> > However, your comment about mixed traffic bothers me quite a bit. 
> 
> Good, it was supposed to ;-)
> 
> > A very ordinary mix of traffic for mobile nodes will probably be
> > SRTP (secure RTP) media probably over ROHC header compression, but
> > using IPsec for most other signaling. This is an extremely appealing
> > combination since the high bandwidth media is heavily optimized, but
> > the relatively low bandwidth signaling is fully protected.
> 
> As always, you need someone to do a security analysis of the
> proposed combination before you can say with any confidence that a
> particular combination looks secure.
> 
> You have to look for weaknesses not only in the protocols themselves,
> but also in exactly how they're stapled together.  As a good example
> of a flaw of this form, early versions of the GSSAPI authentication
> scheme for IKE (draft-ietf-ipsec-isakmp-gss-auth-07.txt) allowed the
> GSSAPI tokens to be cut & pasted between IKE sessions, allowing for a
> man-in-the-middle attack.
> 
> Note that I'm not volunteering to do the analysis for this protocol..
> 
> 					- Bill
>