Subject: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Mar 2004 09:56:08 -0800

Two issues coming out of WG Last Call need to be resolved prior to sending
draft-ietf-send-ndopt-04.txt to the IESG. For reference, the issues can be
found at:

http://users.piuha.net/jarkko/publications/send/issues/issue68.txt
http://users.piuha.net/jarkko/publications/send/issues/issue67.txt

Issue 68: Explicit padding length field v.s. implicit padding length as a
result of message and field length.

Suggested resolution: The draft currently has an explicit padding length, so
remain with that.

Issue 67: Possible implementation variability when nonce omitted from RA.

Suggested resolution: Add following text to paragraph 2, Section 5.3.3, to
guide implementation:

"Omitting the nonce value may, however, cause
the host to ignore the router's advertisement, unless the clocks in
these nodes are sufficiently synchronized so that timestamps can be
relied on."

Please send any comments to the list prior to Tues., March 16.

            jak

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Mar 2004 12:06:26 +0200 (EET)

> Suggested resolution: The draft currently has an explicit padding length, so

Well, having raised the issue, I'm again repeating that it seems
obvious to use implicit padding length.  This is what AFAIR all
ND-related specifications use, and is very common case to deal with
padding as well.  Quite simply "Pad Length" seems to be redundant
information, and any unnecessary information complicates the
specification.  (We could change it to an "MBZ" Reserved field, and
reuse it later on if needed.)

But if there's strong consensus otherwise, I can live with explicit 
padding as well.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 12 Mar 2004 12:15:56 +0200

> Suggested resolution: The draft currently has an explicit padding 

If we had a comment from an implementor (Jon?), that would be great.
I'm willing to go either way, and this seems mostly like an issue
of which way is easier to implement.

> these nodes are sufficiently synchronized so that timestamps can be

Ok to me.

--Pekka

---

From: Jonathan Wood <[email-masked]>
Date: Fri, 12 Mar 2004 10:42:58 -0800

> of which way is easier to implement.

I found that I never used explicit pad lengths (and since I
implemented draft-arkko-send-ndopt-00 only the certificate option
had a pad length).

ASN.1 encoded data proved easy enough to parse with just the
length information in the encoding. The signature length was a
bit trickier - OpenSSL has a function that provides the signature
length based on the key. However, if this function cannot be
applied to all key types, then perhaps the pad length (or an explicit
signature length) field might be needed. A crypto expert can address
this better than I.

When the trust anchor name type is 1 (DER Encoded X.501 Name),
the length is in the DER encoding. However, this is not true for FQDNs.
Processing FQDNs without an explicit pad or length field is harder,
since if the name does not end on an 8 byte boundary, the receiver will
need to walk though the padding to find the end of the name. This would
also be an (unusual) instance of requiring a receiver to
interpret pad values (since it would need to find a non-zero value to
infer the boundary between the end of the name and the start of the
padding). Perhaps it would be better to go back to an explicit name 
length
for this option...

Jon

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 15 Mar 2004 11:44:50 +0200

Jon,

> length information in the encoding....
>
> ... Perhaps it would be better to go back to an explicit name length
> for [FQDN names]...

Do I read this correctly if I assume that you prefer the current
explicit padding length?  That is, even though it is not strictly
needed for DER encoded ANS.1, you see other cases where it would
be useful?

--Pekka

---

From: Jonathan Wood <[email-masked]>
Date: Mon, 15 Mar 2004 10:13:18 -0800

> needed for DER encoded ANS.1, you see other cases where it would

I think it's necessary only in one case - trust anchor options, for 
FQDNs.
Elsewhere is seems to be useless mechanism. Would is be reasonable
to just include a length for trust anchor options?

Jon

---

From: "James Kempf" <[email-masked]>
Date: Mon, 15 Mar 2004 11:07:02 -0800

So based on Jon's input, I'd like to propose the following specific
revisions to the current draft text to resolve Issue 68:

Section 5.2:

Remove Pad Length field from message diagram, make Reserved.

Remove Pad Length description in following text.

Section 6.2.4:

Remove Pad Length field from message diagram, make part of Reserved field.

Remove Pad Length description in following text.

Comments?

            jak

----- Original Message ----- 
From: "Jonathan Wood" <[email-masked]>
To: "Pekka Nikander" <[email-masked]>
Cc: "SEND WG" <[email-masked]>
Sent: Monday, March 15, 2004 10:13 AM
Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt

> This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you believe this message has been sent to you in error,
please notify the sender by replying to this transmission and delete the
message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 17 Mar 2004 15:10:36 +0200

> Remove Pad Length description in following text.

Ok to me.  How about the explicit length for FQDN?  Does it
require any changes?  (Don't have time to check the draft now,
sorry about that.)

--Pekka

---

From: "James Kempf" <[email-masked]>
Date: Wed, 17 Mar 2004 09:23:15 -0800

John's recommendation if I understand correctly was to keep the pad length
for the trust anchor option. Between the pad length, total option length,
and fixed field sizes it should be possible to calculate the FQDN size.

            jak

----- Original Message ----- 
From: "Pekka Nikander" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Jonathan Wood" <[email-masked]>; "SEND WG"
<[email-masked]>
Sent: Wednesday, March 17, 2004 5:10 AM
Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt