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