RE: CTP and CARD Drafts

Ok, All makes sense. I am just wondering what the course of action would be
if CTP does not meet Rohc needs?

Madjid

-----Original Message-----
From: James Kempf [mailto:[email protected]]
Sent: Tuesday, March 09, 2004 4:56 PM
To: Nakhjiri Madjid-MNAKHJI1; [email protected]
Cc: [email protected]
Subject: Re: [Seamoby] CTP and CARD Drafts


ROHC is considered to be a potential "customer" of CTP, and therefore a
review by ROHC should determine if it would meet their needs. In general,
ADs have an obligation to ensure that a document receives sufficient review
prior to submitting it to the IESG. The ROHC group won't be looking for
specific features to support the ROHC application, but whether they can
build their header compression context transfer on top of CTP.

        jak

----- Original Message ----- 
From: "Nakhjiri Madjid-MNAKHJI1" <[email protected]>
To: "'James Kempf'" <[email protected]>; <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, March 09, 2004 2:47 PM
Subject: RE: [Seamoby] CTP and CARD Drafts


> Is it customary that a draft is reviewed by another WG before going to
IESG?
> Would the CTP draft go to IESG after ROHC review?
> What if it is not customized enough for Rohc application?
>
> Madjid
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> James Kempf
> Sent: Thursday, March 04, 2004 2:08 AM
> To: [email protected]
> Cc: [email protected]
> Subject: [Seamoby] CTP and CARD Drafts
>
>
> I spoke with Allison and Thomas Narten this week about the Seamoby drafts.
> The CTP draft is currently undergoing review by the ROHC WG. The CARD
draft
> has undergone IESG review. The following list contains the issues and a
> suggested resolution.
>
> 1) (This issue applies to CTP too) CARD requests allocation of a number of
> ICMP type codes. These type codes are limited to 255 total. Since CARD is
> experimental, it is possible that it will never be deployed and the type
> codes will therefore become unavailable for other protocols that might be
> deployed.
>
> Suggested solution: Seamoby will ask IANA for a single type code per IP
> version, one for IPv4 and one for IPv6, that is used for all Seamoby ICMP
> based protocols. The subtype code will indicate the actual message type.
> Seamoby will generate a third draft with IANA instructions (which I
> volunteer to author) that the two protocol drafts will refer to.
>
> 2) Ted Hardie expressed an objection to the use of multicast. The
objection
> was that the amount of data that would have to be multicast would be
> expected to be large. Also, as is the case with the ICMP types, multicast
> would consume an IPv4 multicast address for an experimental protocol that
> would probably never be deployed.
>
> Suggested solution: remove multicast from the protocol for initial
> publication.
>
> 3) Russ Housley gave the following editorial comments:
>
>  Expand 'AP' and 'PCF' the first time they are used.
>
>   In section 3.2: s/optimized handover/optimal handover/
>
> Suggested solution: fix the text.
>
> 4) Security issues. From Russ Housley:
>
> Section 4.6 and section 5.2.1 say:
>   >
>   > IPSec ESP MUST be used with a non-null integrity protection and
>   > origin authentication algorithm and SHOULD be used with a non-null
>   > encryption algorithm for protecting the confidentiality of the CARD
>   > information.
>   >
>   This is not sufficient.  Where do the cryptographic keys come from?
>   Is IKE required?
>
>   I expected section 6.3 to discuss the establishment of security
>   associations for IPsec ESP, but it does not.
>
> Related followup from Steve Bellovin:
>
> I agree with Russ' comments on establishing IPsec SAs.  Beyond that, how
> does a mobile node know who is authorized to be an AR?  This is especially
> problematic when roaming between domains.
>
> Protecting ICMP messages with IPsec can be difficult.  The authors need to
> do a full-fledged design to make sure that it can be done.  The experience
> of the SEND group may be relevant.
>
> What in the CARD messages may need to be confidential, and hence require
> encryption?  The analysis needs to be done here, so that users of this
spec
> know when to turn it on.
>
> Suggested solution: I volunteer come with some text to replace the current
> security considerations section that utilizes the SEND router certificate
> and CGA to verify the node's right to claim the address, and that gives a
> short discussion of threats. I'll negotiate with Russ and Steve on the
text.
>
>             jak
>
>
>
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby
>