Subject: More review comments on cellular hosts...

From: Thomas Narten <[email-masked]>
Date: Tue, 04 Jun 2002 14:44:58 -0400

Here are some additional review comments from various IESG reviewers:

> RFC 3155 should be added to the normative refs in my
> opinion.  I'm not opposed to keeping the non-normative
> ref to the 2.5/3G TCP issues draft that started me on
> this.

Another reviewer:

> Comments on draft-ietf-ipv6-cellular-host-02.txt

> 2.4.1 says that the host must support receipt of
> Neighbor Solicitation and Advertisement messages.
> But 2.5.1 says "will not be sent or received" which might seem
> conflicting at least with respect to the receive part.

> DAD for 3041 addresses?
> Will the router only have a link-local address on the link?
> If not, how to detect a 3041 conflicting with one of the routers
> addresses?

> 2.12 - 3041 MAY be used. Do we want something stronger?

> MLD:
>    multicast services. There is no need for MLD if the host only 
>    supports the well-known (hard coded in IPv6 implementations) link 
>    local multicast addresses. MLD is not used for listening on such 
>    addresses. 
> Only applies to all-nodes address (ff02::1). 
> RFC2461 says that a node must join
> the solicited-node multicast address(es) on multicast-capable interface,
> and point-to-point interface are specifically treated as
>      point-to-point - Neighbor Discovery handles such links just like
>                       multicast links.
> 	
> Thus per the letter of the specifications MLD must be implemented
> by cellular hosts.

> This also effects the need to support RFC2711 (section 2.10).

> 2.11
>    (IPv4 vs. IPv6). Cellular hosts should not support configured or 
>    automatic tunnels to avoid unnecessary tunneling over the air 
>    interface, unless there are no other mechanisms available. Tunneling 
>    can lead to poor usage of available bandwidth. 

> The bandwidth concern is a reason not to *use* tunneling, but
> the point about it being a last resort seems to say that it would
> be useful to implement this. However, the text "should bot support"
> seems to mean "should not implement".
> Same issue for section 2.13 on 6to4 tunneling.

> 2.15: and all useful hosts have at least a link-local address
> and a larger scope address. So why not say "must be supported"
> instead of qualifying it with a tautology?

> 2.16 - add reference to RFC 3152. RFC 1886 talks about ip6.int
> thus the ip6.arpa document must be referenced.

> Section 3 - how about adding that future IPsec algoritms might be
> useful/supported in the future.
> Currently only DES, HMAC-MD5, and HMAC-SHA1 are listed.

More comments:

> AES is coming, should be supported in fugure. Mention this?
> 
> The docuent is vague on key management. It basically doesn't say what
> will be used for key  management, and that begs the question of what
> kind of interoperability will be achieved.
> 
> If AKA is the solution, then this needs to be made more clear in the
> document.  Isn't it the case that AKA is what the overall
> theme for 3GPP?
> 
> What is needed is a clear statement on how interoperability with
> regards to key management will be obtained. If this is not actually
> known today, then the document should just say we haven't decided yet,
> but will decide down the road.
> 
> The document lists 7 authors. This number is considered on the high
> side. See draft-rfc-editor-author-lists-00.txt (which is being Last
> Called as we speak).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Jun 2002 22:54:09 +0300

Thanks Thomas (and the IESG) for the comments.

>>ref to the 2.5/3G TCP issues draft that started me on

Ok!

>>conflicting at least with respect to the receive part.

Right. 2.4.1 and it's latest revs that have been discussed
on the list is correct here. 2.5.1 should say "Duplicate Address
Detection will not be initiated by the cellular host.".

>>If not, how to detect a 3041 conflicting with one of the routers

Router will have only a link-local address on the link.

>>2.12 - 3041 MAY be used. Do we want something stronger?

Well, isn't the current keyword for 3041 essentially a MAY
in the v6 standards? Note also that the cellular network
privacy situation is not as bad as, say my fixed IP DSL
situation. The prefixes change over time, as you turn off/on
the device or go temporarily out of coverage.

>>Thus per the letter of the specifications MLD must be implemented

Discussion ongoing on the list though, see e.g. Brian's
e-mail.

>>This also effects the need to support RFC2711 (section 2.10).

Yes. We could clarify the text in 2.10 to say that it is required
if you do MLD.

>>Same issue for section 2.13 on 6to4 tunneling.

These have been, I believe, satisfactorily resolved after a
discussion with Margaret: basically, we are letting the ngtrans
design team to specify this, in the documents.

>>instead of qualifying it with a tautology?

Ok!

>>thus the ip6.arpa document must be referenced.

Sounds good.

>>Currently only DES, HMAC-MD5, and HMAC-SHA1 are listed.

We actually had that at one point in time. We could add a note that
some good algorithms are coming in the future. I fear that AES isn't
an RFC yet. Don't want to reference I-Ds.

>>but will decide down the road.

All of the above is true, but then again this is an IP layer document
and doesn't specify a complete system. Basically, I believe we are more
or less equally vague with the IPv6 standards.

In practise, the situation is likely the following:

  * IPsec in general will use IKE or its successors.
  * The IP multimedia system will use IPsec, but key itself via AKA-generated keys
  * Web, wap, etc. is likely to use TLS.

I'm open to suggestions but I'm not sure exactly what we can say.
Can we mandate key management and its interoperability in IPv6
standards?

Jari