Re: Status of Seamoby drafts

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
>
>
>
>