D107 Section 5.5 nits

From: Jari Arkko
Subject: [Mobike] design draft issue: section 5.5 nits
Date: Wed, 21 Dec 2005 12:53:15 +0200

|    If the addresses are part of the certificate then it is
|    not necessary to execute the weaker return routability check.  The
|    return routability check is a form of authorization check, although
|    it provides weaker guarantees than the inclusion of the IP address as
|    a part of a certificate.  If multiple addresses are communicated to
|    the remote peer then some of these addresses may be already verified
|    even if the primary address is still operational.


s/the weaker/the/ (the strength is explained in next sentence)

Also, it seems like there is some text missing here that we
had in the protocol draft about the need to have some authority
involved in the certs... surely the pure inclusion of data in
a self-signed certificate, for instance, does not make the
data reliable.

I do not understand the last sentence. I guess you are trying
to say that verification can take place in parallel with ongoing
use of another, current address pair?

|    Another option is to use the [I-D.dupont-mipv6-3bombing] approach
|    which suggests to perform a return routability check only when an
|    address update needs to be sent from some address other than the
|    indicated preferred address.

I would delete this paragraph. There are a zillion variations
of the return routability procedure, and there is no need
to point to one of the variants here, particularly if that variant
has not been in use in other contexts.

From: Tero Kivinen
Subject: [Mobike]  D107 design draft issue: section 5.5 nits
Date: Tue, 3 Jan 2006 18:47:15 +0200

Jari Arkko writes:
| |    If the addresses are part of the certificate then it is
| |    not necessary to execute the weaker return routability check.  The
| |    return routability check is a form of authorization check, although
| |    it provides weaker guarantees than the inclusion of the IP address as
| |    a part of a certificate.  If multiple addresses are communicated to
| |    the remote peer then some of these addresses may be already verified
| |    even if the primary address is still operational.
| 
| s/the weaker/the/ (the strength is explained in next sentence)

Done.

| Also, it seems like there is some text missing here that we
| had in the protocol draft about the need to have some authority
| involved in the certs... surely the pure inclusion of data in
| a self-signed certificate, for instance, does not make the
| data reliable.

I think adding that text to the protocol draft was completely
unnessarely in the first place, as of course certificates needs to be
validated before you use them. 

| I do not understand the last sentence. I guess you are trying
| to say that verification can take place in parallel with ongoing
| use of another, current address pair?

No, it means that if we have already done return routability check or
if the IP-address was listed in the certificate, then we might already
have verified some of those addresses resently. I.e. for example if we
move between two address pairs, we do not necessarely need to do
return routability checks for them for every time. I agree that the
"even if the current address is still operational." is quite confusing
there, so I removed it.

| |    Another option is to use the [I-D.dupont-mipv6-3bombing] approach
| |    which suggests to perform a return routability check only when an
| |    address update needs to be sent from some address other than the
| |    indicated preferred address.
| 
| I would delete this paragraph. There are a zillion variations
| of the return routability procedure, and there is no need
| to point to one of the variants here, particularly if that variant
| has not been in use in other contexts.

True. Deleted (and the reference, as it was last one).