D116 Misc comments from Pasi
From: Pasi Eronen
Subject: [Mobike] Design draft, misc. comments
Date: Fri, 23 Dec 2005 14:25:33 +0200
- Section 1, "for example when using SecurID cards" -> "for example,
when using human-operated token cards"
- Section 3.2: "Each peer selects one of its IP addresses as the
preferred address which is used for subsequent communication."
There's some conflict here. It's the initiator who selects
which addresses are used for subsequent communication (except
in relatively rare situations, ie. responder address changes).
- Section 4: "The MOBIKE protocol should be able to perform...":
this text may need to be rewritten once we either come up
with a reasonable definition for "preferred address", or
get rid of the term completely.
- Section 4: The talk about "MOBIKE daemon" creates the impression
that there typically would be both an "IKEv2 daemon" and
"MOBIKE daemon", running as separate processes. While this is
not impossible, I would find it a very strange way to implement
a relatively minor extension to IKEv2. (After all, if we implement
some other IKEv2 extension like draft-nir-ikev2-auth-lt,
we don't call it the "Repeated Authentication Daemon" or something.)
- Section 5.1.4, 1st paragraph: closing parenthesis missing.
- Section 5.2.1, a couple of informative references might be
in order (UNSAF, MIDCOM, NSIS NATFW)
- Section 6.3: "The selected format needs to be flexible enough to
include additional information in future versions of the protocol
(e.g. to enable load balancing). This may be realized with an
reserved field, which can later be used to store additional
information. As there may arise other information which may have to
be tied to an address in the future, a reserved field seems like a
prudent design in any case."
IMHO it would be quite difficult to design the protocol in a way
that would totally prevent future extensions from sending
additional information. But currently we don't have any "reserved"
fields there (simply because they're not needed -- the normal
IKEv2 extension mechanisms will allow us to add more stuff later).
- References: should draft-ietf-mobike-protocol be normative?
From: Tero Kivinen
Subject: [Mobike] D116 Design draft, misc. comments
Date: Tue, 3 Jan 2006 20:44:50 +0200
Pasi.Eronen@nokia.com writes:
| - Section 1, "for example when using SecurID cards" -| "for example,
| when using human-operated token cards"
Done.
| - Section 3.2: "Each peer selects one of its IP addresses as the
| preferred address which is used for subsequent communication."
| There's some conflict here. It's the initiator who selects
| which addresses are used for subsequent communication (except
| in relatively rare situations, ie. responder address changes).
In mobike-protocol it is initiator. Here we also describe other
options. No conflict, we simply do not fully support that scenario in
current protocol (i.e. responder preference is ignored).
| - Section 4: "The MOBIKE protocol should be able to perform...":
| this text may need to be rewritten once we either come up
| with a reasonable definition for "preferred address", or
| get rid of the term completely.
Again disagree. This is not describing only the current protocol, but
also design choises behind the current protocol. That means we need to
describe things in more general ways than what current protocol
document requires.
| - Section 4: The talk about "MOBIKE daemon" creates the impression
| that there typically would be both an "IKEv2 daemon" and
| "MOBIKE daemon", running as separate processes. While this is
| not impossible, I would find it a very strange way to implement
| a relatively minor extension to IKEv2. (After all, if we implement
| some other IKEv2 extension like draft-nir-ikev2-auth-lt,
| we don't call it the "Repeated Authentication Daemon" or something.)
True. Perhaps MOBIKE module would be better term. Changed to MOBIKE
module.
| - Section 5.1.4, 1st paragraph: closing parenthesis missing.
Fixed.
| - Section 5.2.1, a couple of informative references might be
| in order (UNSAF, MIDCOM, NSIS NATFW)
Sure, give RFC / Internet-draft names, I will add them.
| - Section 6.3: "The selected format needs to be flexible enough to
| include additional information in future versions of the protocol
| (e.g. to enable load balancing). This may be realized with an
| reserved field, which can later be used to store additional
| information. As there may arise other information which may have to
| be tied to an address in the future, a reserved field seems like a
| prudent design in any case."
|
| IMHO it would be quite difficult to design the protocol in a way
| that would totally prevent future extensions from sending
| additional information. But currently we don't have any "reserved"
| fields there (simply because they're not needed -- the normal
| IKEv2 extension mechanisms will allow us to add more stuff later).
Actually we do. We have notification data, that is either empty of
fixed length, which means we can add stuff to it.
| - References: should draft-ietf-mobike-protocol be normative?
I do not think so. It is not mandatory to read current protocol to
understand why we ended up there, and what other options were
considered and rejected.
From: "Tschofenig, Hannes"
Subject: Re: [Mobike] D116 Design draft, misc. comments
Date: Wed, 4 Jan 2006 13:41:06 +0100
| | - Section 5.2.1, a couple of informative references might be
| | in order (UNSAF, MIDCOM, NSIS NATFW)
|
| Sure, give RFC / Internet-draft names, I will add them.
here are the references:
[UNSAF] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
for midcom we could reference:
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
and
[MIDCOM-MIB] Quittek, J., Stiemerling, M. and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", draft-ietf-midcom-mib-05.txt (work in progress), March 2005.
here is the nsis reference:
[NSISNATFW] Stiemerling, M., Tschofenig, H. and C. Aoun, "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Internet-Draft draft-ietf-nsis-nslp-natfw-08, October 2005.
From: Tero Kivinen
Subject: Re: [Mobike] D116 Design draft, misc. comments
Date: Thu, 5 Jan 2006 13:12:57 +0200
| here are the references:
|
| [UNSAF] Daigle, L. and IAB, "IAB Considerations for UNilateral
| Self-Address Fixing (UNSAF) Across Network Address
| Translation", RFC 3424, November 2002.
|
|
| for midcom we could reference:
|
| [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
| Rayhan, "Middlebox communication architecture and
| framework", RFC 3303, August 2002.
Added those.
| [MIDCOM-MIB] Quittek, J., Stiemerling, M. and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", draft-ietf-midcom-mib-05.txt (work in progress), March 2005.
Is the mib here really relevant for the mobike design? I think the
architecture and framework should be enough. I didn't add this one
yet.
| here is the nsis reference:
|
| [NSISNATFW] Stiemerling, M., Tschofenig, H. and C. Aoun, "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Internet-Draft draft-ietf-nsis-nslp-natfw-08, October 2005.
Added that.
From: "Tschofenig, Hannes"
Subject: AW: [Mobike] D116 Design draft, misc. comments
Date: Thu, 5 Jan 2006 13:05:53 +0100
| Is the mib here really relevant for the mobike design? I think the
| architecture and framework should be enough. I didn't add this one
| yet.
it is ok for me to reference just the framework. i guess that everyone
then already understands what is meant.