Re: CTP and CARD Drafts

I assume Allison would at that point return the draft to us with their
comments and require us to fix it before sending it to the IESG. She might
edit the comments based on her technical assessment if there were some that
she thought were not appropriate.

            jak

----- Original Message ----- 
From: "Nakhjiri Madjid-MNAKHJI1" <[email protected]>
To: "'James Kempf'" <[email protected]>; <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, March 09, 2004 3:21 PM
Subject: RE: [Seamoby] 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
> >
>