Subject: RE: [Seamoby] CTP and CARD Drafts

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Mar 2004 17:21:06 -0600

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-masked]]
Sent: Tuesday, March 09, 2004 4:56 PM
To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Cc: [email-masked]
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-masked]>
To: "'James Kempf'" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
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-masked] [mailto:[email-masked]]On Behalf Of
> James Kempf
> Sent: Thursday, March 04, 2004 2:08 AM
> To: [email-masked]
> Cc: [email-masked]
> 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-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
>

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Mar 2004 15:52:59 -0800

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

---

From: Allison Mankin <[email-masked]>
Date: Tue, 09 Mar 2004 20:18:22 -0800

All,

Actually, there's been a little bit of misunderstanding of my message about the
CTP draft, which is easy to have happen, because we were all very busy during
the IETF week.  What I meant was that I had to talk with some ROHC people about CTP,
not that ROHC _WG_ review of the document would be required.  

Why is this?  It's due to some commitment that was made in the Vienna Seamoby 
meeting to deliver Seamoby with a use case, which I understood would probably be
header compression context.  The minutes show an action item to work with Carsten
Bormann to make this concrete.  We discussed the need for the use case that
would describe a context very well defined in IETF, with ROHC header compression
meeting that criterion.  If contexts for context transfer are just open-ended,
and there isn't an clear use case, it's hard to build support for this
protocol in the broader IETF (not only the IESG - we had a lot* of questions
about this charter item when the WG was formed).  

So, I've done a little talking and looking at the document.  The example of a
service that was supposed to be covered in Appendix C is missing.  There is no 
companion document describing a use case.  What's up?

Allison

http://www.ietf.org/proceedings/03jul/index.html