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

[no subject]



I don't feel we underspecified IPsec. We simply recommend using IPsec between ARs when sensitive data is being transferred and saying that the SA must be permanent and prior to the CT that is going on. You cannot do an IKE during CTP, it defeats the purpose of CTP to do an exchange that takes 3-4 round trips. That is different than saying the details of IPsec and IKE are TBD (the latter is more of a handwaving IMHO).

Could you please send the reference on the EAP doc?

Thanks,

Madjid

-----Original Message-----
From: James Kempf [<a  href="mailto:kempf";>mailto:kempf</a> at docomolabs-usa.com]
Sent: Wednesday, July 21, 2004 5:24 PM
To: Nakhjiri Madjid-MNAKHJI1; rajeev at iprg.nokia.com; Vijay Devarapalli
Cc: seamoby at ietf.org
Subject: Re: [Seamoby] 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 &quot;IPsec pixy dust&quot; 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: &quot;Nakhjiri Madjid-MNAKHJI1&quot; &lt;Madjid.Nakhjiri at motorola.com&gt;
To: &quot;'James Kempf'&quot; &lt;kempf at docomolabs-usa.com&gt;; &lt;rajeev at iprg.nokia.com&gt;;
&quot;Vijay Devarapalli&quot; &lt;vijayd at iprg.nokia.com&gt;
Cc: &lt;seamoby at ietf.org&gt;
Sent: Wednesday, July 21, 2004 1:26 PM
Subject: RE: [Seamoby] Status of Seamoby drafts


&gt; Hi,
&gt;
&gt; I am trying to understand what we are debating:
&gt;
&gt; a) The assumption of pre-established shared secret for IKE between ARs is
not practical?
&gt; You should not go through a burden of shared secret configuration, and
should use certificates?
&gt;
&gt; or
&gt;
&gt; b) IKE is not practical? and some other key exchange/ SA management method
must be used.
&gt;
&gt; 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.
&gt;
&gt; 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).
&gt;
&gt; From the discussions I have seen, it is not clear what we are debating?
&gt;
&gt; Regards,
&gt;
&gt; Madjid
&gt;
&gt;
&gt;
&gt; -----Original Message-----
&gt; From: seamoby-bounces at ietf.org [<a  href="mailto:seamoby-bounces";>mailto:seamoby-bounces</a> at ietf.org]On
&gt; Behalf Of James Kempf
&gt; Sent: Friday, July 16, 2004 5:52 PM
&gt; To: rajeev at iprg.nokia.com; Vijay Devarapalli
&gt; Cc: seamoby at ietf.org
&gt; Subject: Re: [Seamoby] Status of Seamoby drafts
&gt;
&gt;
&gt; I think that if each router shares a symmetric security association with
&gt; each other router, secured by a shared key, and there are n routers, the
&gt; total number of keys is sum i over n-1 to 0 ( i ). 5 routers require 4 + 3
+
&gt; 2 +1 keys, 3 routers require 2 + 1 keys, etc. I agree that it is a lot
less
&gt; than n(n-1), I don't know where he got that number. I think the point he
is
&gt; trying to make is that a symmetric keying scheme would result in a
&gt; configuration problem for a large network.
&gt;
&gt; But my response to him is that it isn't a problem for this document to
&gt; solve, at least, not yet. I don't think we need to engage him on the
&gt; accuracy of his estimate.
&gt;
&gt;             jak
&gt;
&gt;
&gt; ----- Original Message ----- 
&gt; From: &quot;Rajeev Koodli&quot; &lt;rajeev at iprg.nokia.com&gt;
&gt; To: &quot;Vijay Devarapalli&quot; &lt;vijayd at iprg.nokia.com&gt;
&gt; Cc: &quot;James Kempf&quot; &lt;kempf at docomolabs-usa.com&gt;; &lt;seamoby at ietf.org&gt;
&gt; Sent: Friday, July 16, 2004 3:23 PM
&gt; Subject: Re: [Seamoby] Status of Seamoby drafts
&gt;
&gt;
&gt; &gt;
&gt; &gt; Vijay, Jim,
&gt; &gt;
&gt; &gt; Vijay Devarapalli wrote:
&gt; &gt;
&gt; &gt; &gt; &gt; Since context transfer security is an n by n problem, establishing
the
&gt; SAs
&gt; &gt; &gt; &gt; to protect inter-router transfers is not an easy thing.  For this
&gt; reason one
&gt; &gt; &gt; &gt; might conclude that pre-shared keys are difficult, since n(n-1) of
&gt; them
&gt; &gt; &gt; &gt; would be necessary.  On the other hand, is it being suggested that
&gt; each
&gt; &gt; &gt; &gt; router needs to be provisioned with a certificate? On reading the
&gt; draft it
&gt; &gt; &gt; &gt; isn't clear what's being recommended (or even considered).
&gt; &gt; &gt;
&gt; &gt;
&gt; &gt; I could not parse the &quot;n by n&quot; problem. Any pointers ?
&gt; &gt; Why is the order higher than pairwise SA between routers, which might
&gt; &gt; already exist ?
&gt; &gt;
&gt; &gt; -Rajeev
&gt; &gt;
&gt; &gt;
&gt; &gt; &gt;
&gt; &gt; &gt; this comment is valid. but since we assume the access routers are
&gt; &gt; &gt; part of the same administrative domain, they are provisioned with
&gt; &gt; &gt; the required certificates to run IKE. (?)
&gt; &gt; &gt;
&gt; &gt; &gt; Vijay
&gt; &gt; &gt;
&gt; &gt; &gt; _______________________________________________
&gt; &gt; &gt; Seamoby mailing list
&gt; &gt; &gt; Seamoby at ietf.org
&gt; &gt; &gt; <a  href="https://www1.ietf.org/mailman/listinfo/seamoby";>https://www1.ietf.org/mailman/listinfo/seamoby</a>
&gt; &gt;
&gt; &gt;
&gt;
&gt;
&gt;
&gt; _______________________________________________
&gt; Seamoby mailing list
&gt; Seamoby at ietf.org
&gt; <a  href="https://www1.ietf.org/mailman/listinfo/seamoby";>https://www1.ietf.org/mailman/listinfo/seamoby</a>


_______________________________________________
Seamoby mailing list
Seamoby at ietf.org
<a  href="https://www1.ietf.org/mailman/listinfo/seamoby";>https://www1.ietf.org/mailman/listinfo/seamoby</a>



</pre>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<hr>
<ul><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><a name="02764" href="msg02764.html">Re: [Seamoby] Status of Seamoby drafts</a></strong>
<ul><li><em>From:</em> James Kempf</li></ul></li>
</ul></li></ul>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<ul>
<li>Prev by Date:
<strong><a href="msg02762.html">[Seamoby] CARD issue tracker updated - issue#52 and #53</a></strong>
</li>
<li>Next by Date:
<strong><a href="msg02764.html">Re: [Seamoby] Status of Seamoby drafts</a></strong>
</li>
<li>Previous by thread:
<strong><a href="msg02761.html">Re: [Seamoby] Status of Seamoby drafts</a></strong>
</li>
<li>Next by thread:
<strong><a href="msg02764.html">Re: [Seamoby] Status of Seamoby drafts</a></strong>
</li>
<li>Index(es):
<ul>
<li><a href="maillist.html#02763"><strong>Date</strong></a></li>
<li><a href="threads.html#02763"><strong>Thread</strong></a></li>
</ul>
</li>
</ul>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
</body>
</html>