Re: Status of Seamoby drafts

Jim,

the point is even if CTP were to be a proposed standard, it
shouldnt be specifying what cryptographic suites to use.
thats part of IPsec specs.

Vijay

James Kempf wrote:

> Vijay,
> 
> Thanx for your comments, they essentially echo what I sent to Dave in email
> yesterday.
> 
> Basically, since CTP is an experimental protocol, I'm proposing to Dave that
> the operational considerations for CTP security be worked out as part of the
> process of preparing it for reintroduction to Standards Track. In addition,
> there is a WG already working on routing protocol security. I think it would
> simplify configuration if CTP security could reuse as much of that work as
> possible (for example, the certificate profile) to avoid duplication.
> Therefore, I've proposed to add the following text to the draft at the end
> of Section 6.2:
> 
>     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.
> 
>         jak
> 
> 
> 
> ----- Original Message ----- 
> From: "Vijay Devarapalli" <[email protected]>
> To: "James Kempf" <[email protected]>
> Cc: <[email protected]>
> Sent: Thursday, July 15, 2004 11:04 AM
> Subject: Re: [Seamoby] Status of Seamoby drafts
> 
> 
> 
>>Jim,
>>
>>
>>>draft-ietf-ctp: OPS AD Dave Kessens had some major Discuss comments
> 
> about
> 
>>>the lack of detail in the definition of how IKE is used, and lack of
>>>discussion of "correctness" such as in draft-ietf-eap-keying. I'm
> 
> currently
> 
>>>working with Dave and Allison to resolve the Discuss.
>>
>>I looked up the security comments from the OPS directorate.
>>
> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=839&filename=draft-ietf-seamoby-ctp
> 
>>>For example, Section 6.2 talks about using of IKE to dynamically
> 
> negotiate
> 
>>>keys for protection of Inter-Router traffic.  However, it doesn't say
> 
> what
> 
>>>IKE modes need to be implemented, or what IPsec ciphersuites are
> 
> required.
> 
>>this doesnt make a lot of sense to me.
>>
>>we can only say that there must be confidentiality protection
>>for the secure channel between the access routers. we also say
>>ESP in transport mode must be used. we also say a non-null
>>encryption algorithm is to be used.
>>
>>implementations have to follow IPsec specifications.
>>
>>
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05.txt
> 
>>specifies what algorithms to use with IKE.
>>
>>http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-06.txt
>>specifies what cryptographic suites to use with IPsec.
>>
>>CTP actually doesnt care which cipher suites or algorithms from
>>the above two drafts are used as long as the requirements for
>>non-null encryption algorithm, authentication, and confidentiality
>>protection is achieved.
>>
>>
>>>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).
>>
>>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
>>
>>
>>
>>
> 
> 
>