Re: Status of Seamoby drafts

I don't really think we are debating anything, at least I'm not.

I believe Dave Kessen's comments are a reaction to a history of
underspecifying how IPsec is used in many IETF standards. See RFC 2461 as an
example. This approach has been called "IPsec pixy dust" and it has indeed
been a problem.

What I think he failed to take into account is that this is not a standards
track draft. Part of the exercise in preparing it for standards track is
understanding what is necessary in the area of security between routers. The
draft as it stands now poses no threat to router security, it just is not
very specific about how that is done, and so there could be an
interoperability problem if two routers do not use IPsec in the same way.
There are other WGs working in this area, and ideally the requirements for
interrouter security for CTP and CARD should be brought to them. I'm
proposing the following text for Section 6 of the CTP draft:

    The details of IKE key exchange and other details of the IPsec security
    associations between routers are to be determined as part of the
    research phase associated with finalizing the protocol for
    standardization. Prior to standardization, these details must be
   determined. Other working groups are currently working on general
   security for routing protocols.
    Ideally, a solution for CTP will be based on this work, in order to
    minimize operational configuration of routers for different protocols.
    Requirements for CTP will be brought to the appropriate IETF
    routing protocol security working groups for consideration.

Of course, this means someone must go to an RPSEC meeting and talk about the
requirements, at some point.

Dave also had some comments about the applicability of context transfer, but
I believe they are not an appropriate topic for this document. I'm
recommending that we simply reference the EAP draft (which talks about this)
or that we revise the CTP requirements RFC, with preference going to the
former, since the IESG wants Seamoby to shut down.

If you want to see Dave's comments, check Draft Tracker. So far, I've not
gotten any response from him about my suggested changes in the draft. :-(

                jak

----- Original Message ----- 
From: "Nakhjiri Madjid-MNAKHJI1" <[email protected]>
To: "'James Kempf'" <[email protected]>; <[email protected]>;
"Vijay Devarapalli" <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, July 21, 2004 1:26 PM
Subject: RE: [Seamoby] Status of Seamoby drafts


> Hi,
>
> I am trying to understand what we are debating:
>
> a) The assumption of pre-established shared secret for IKE between ARs is
not practical?
> You should not go through a burden of shared secret configuration, and
should use certificates?
>
> or
>
> b) IKE is not practical? and some other key exchange/ SA management method
must be used.
>
> Answer to a) The way I see it, doing IKE just in time for CTP is not
practical, since the round trip delays involved in IKE defeats the purpose
of CTP for enhancing the handover in the first place. IF you decide on IKE,
it has to be done way before the handover and between each AR-pair. It does
not matter whether you are using shared secrets or certificates, you are not
saving any round trips. You just have less administrative burden with
certificates, but more investment requirement for the PKI that you have to
put in place.
>
> Answer to b) This is a completely separate issues. Then you have to see
whether you want to use IPsec or something else like TLS (which means
setting up TCP between AR, and we don't want that) or some other security
method. When you decide IPsec, then you need to find an implementation that
does IPsec without IKE (not sure how common that is).
>
> From the discussions I have seen, it is not clear what we are debating?
>
> Regards,
>
> Madjid
>
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of James Kempf
> Sent: Friday, July 16, 2004 5:52 PM
> To: [email protected]; Vijay Devarapalli
> Cc: [email protected]
> Subject: Re: [Seamoby] Status of Seamoby drafts
>
>
> I think that if each router shares a symmetric security association with
> each other router, secured by a shared key, and there are n routers, the
> total number of keys is sum i over n-1 to 0 ( i ). 5 routers require 4 + 3
+
> 2 +1 keys, 3 routers require 2 + 1 keys, etc. I agree that it is a lot
less
> than n(n-1), I don't know where he got that number. I think the point he
is
> trying to make is that a symmetric keying scheme would result in a
> configuration problem for a large network.
>
> But my response to him is that it isn't a problem for this document to
> solve, at least, not yet. I don't think we need to engage him on the
> accuracy of his estimate.
>
>             jak
>
>
> ----- Original Message ----- 
> From: "Rajeev Koodli" <[email protected]>
> To: "Vijay Devarapalli" <[email protected]>
> Cc: "James Kempf" <[email protected]>; <[email protected]>
> Sent: Friday, July 16, 2004 3:23 PM
> Subject: Re: [Seamoby] Status of Seamoby drafts
>
>
> >
> > Vijay, Jim,
> >
> > Vijay Devarapalli wrote:
> >
> > > > Since context transfer security is an n by n problem, establishing
the
> SAs
> > > > to protect inter-router transfers is not an easy thing.  For this
> reason one
> > > > might conclude that pre-shared keys are difficult, since n(n-1) of
> them
> > > > would be necessary.  On the other hand, is it being suggested that
> each
> > > > router needs to be provisioned with a certificate? On reading the
> draft it
> > > > isn't clear what's being recommended (or even considered).
> > >
> >
> > I could not parse the "n by n" problem. Any pointers ?
> > Why is the order higher than pairwise SA between routers, which might
> > already exist ?
> >
> > -Rajeev
> >
> >
> > >
> > > this comment is valid. but since we assume the access routers are
> > > part of the same administrative domain, they are provisioned with
> > > the required certificates to run IKE. (?)
> > >
> > > Vijay
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
>
>
>
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby