search

mxsasha / nrtmv4

Ideas and work on the NRTM v4 protocol and implementations.
5 stars 7 forks source link

correct examples and suggest changes in object format #20

Closed maggarwal13 closed 2 years ago

maggarwal13 commented 2 years ago

Why not use TLS for verifying the trust rather than a separate public key (which is sent in the same channel, enabling MITM attack) ? RPKI RRDP uses TLS

maggarwal13 commented 2 years ago

Which object types are included in NRTMv4? Does IRR implies only route object or publish every object type?

job commented 2 years ago

Why not use TLS for verifying the trust rather than a separate public key (which is sent in the same channel, enabling MITM attack) ? RPKI RRDP uses TLS

The difference between relying exclusively on TLS and the mechanism we have in mind is transport security versus object security. Object security has some advantages over transport security as through object security each processing hop can independently (again) verify the integrity and authenticity of the information at hand.

eshryane commented 2 years ago

Which object types are included in NRTMv4? Does IRR implies only route object or publish every object type?

It's up to the mirror server to decide which object types are included, and the client should be able to handle unknown types:

8.1.  IRR object Validation
..
A mirror client SHOULD be able to handle unknown object classes and
objects that are invalid according to its own validation rules, which
may mean simply discarding them, without rejecting remaining objects
or preventing future updates.
eshryane commented 2 years ago

@mxsasha regarding version numbers in the example in section 5.3.

The Update Notification File example in section 5.3 shows the snapshot is version 2, and the first delta is version 1. However, this is not possible, given Section 3.2 states that the snapshot must be version 1 and Section 3.3.1 states that a new delta must be one greater than the snapshot (i.e. version 2).

Section 3.2 Snapshot Initialization: "The server MUST generate a snapshot for version number one".

Section 3.3.1. Delta Files: "A new Delta File MUST be generated with a new version, one greater than the last Delta File version, or one greater than the last Snapshot File version if there were no prior deltas at all."

Can you review the version numbers used in the example?

eshryane commented 2 years ago

@mxsasha regarding section 6.3. "File format and validation"

Is the quoted-printable encoding required for encoding non-ASCII characters only ? For example, "\n" is used to escape newlines rather than =0D=0A for CRLF in quoted-printable. How do we escape tabs ("\t") backslashes ("\") and double-quotes ("\"") ? Can a line length exceed 76 characters?

Should the "object" value be completely encoded as quoted-printable?

mxsasha commented 2 years ago

@eshryane I think you might be lookng at an older version? I do not see the serial issue in https://htmlpreview.github.io/?https%3A%2F%2Fgithub.com%2Fmxsasha%2Fnrtmv4%2Fblob%2Fmain%2Fdraft-ietf-grow-nrtm-v4.html=#name-file-format-and-validation-4 or https://github.com/mxsasha/nrtmv4/blob/main/draft-ietf-grow-nrtm-v4.xml#L426-L457

Regarding quoted-printable, RFC2045 6.7 indeed specifies a hard requirement of 76 characters. That may not be the best choice then. Happy to talk alternatives. The goal of quoted-printable was to represent plain us-ascii characters as usual, which is by far the most common case, while also not requiring utf-8 compatible HTTP/transport. Some alternatives could be:

eshryane commented 2 years ago

Hi @mxsasha

@eshryane I think you might be lookng at an older version? I do not see the serial issue in https://htmlpreview.github.io/?https%3A%2F%2Fgithub.com%2Fmxsasha%2Fnrtmv4%2Fblob%2Fmain%2Fdraft-ietf-grow-nrtm-v4.html=#name-file-format-and-validation-4 or https://github.com/mxsasha/nrtmv4/blob/main/draft-ietf-grow-nrtm-v4.xml#L426-L457

I see an issue with this version also: I expect a snapshot to be the first version, as we must create a full snapshot first, in the example the snapshot is version 2. I expect the subsequent deltas to have versions 2, 3, 4 (following the snapshot at version 1).

Regarding quoted-printable, RFC2045 6.7 indeed specifies a hard requirement of 76 characters. That may not be the best choice then. Happy to talk alternatives. The goal of quoted-printable was to represent plain us-ascii characters as usual, which is by far the most common case, while also not requiring utf-8 compatible HTTP/transport. Some alternatives could be:

  • Files, including their objects are UTF-8 encoded, i.e. other than needed by JSON we don't escape. I think @job particularly disliked this option, I prefer this one.
  • We use some kind of binary encoding for object content, like base64. Upside: files are plain text, never have encoding issues in transport. Downside: object texts not plainly readable, fairly large overhead for very few non us-ascii characters.

Unfortunately I can't think of a better alternative (I will have a look). Can we define the format as "quoted-printable with exceptions"? This may cause issues for clients as they can't then use an off-the-shelf quoted-printable decoder. I also like to have objects as plainly readable.

eshryane commented 2 years ago

Can we specify the String encoding as in section 2.5 of rfc4627 ?

This will allow us to use a standard encoding that's compatible with JSON, and can be easily parsed.

mxsasha commented 2 years ago

I see an issue with this version also: I expect a snapshot to be the first version, as we must create a full snapshot first, in the example the snapshot is version 2. I expect the subsequent deltas to have versions 2, 3, 4 (following the snapshot at version 1).

Yes - I see what you mean. There is no scenario where there can be a delta with v1, because what would the delta relate to? The idea is that updating to a snapshot of version X gives you identical local data as updating to a delta with version X (when including all intermediate deltas) - and this is not possible with version 1. The only way to get to v1 is through a snapshot. I'll fix this.

Can we specify the String encoding as in section 2.5 of rfc4627 ?

This is perfect - somehow missed this. In fact, it's default Python 3 behaviour:

>>> import json
>>> input = 'foo\nbar🤔'
>>> print(input)
foo
bar🤔
>>> print(json.dumps(input))
"foo\nbar\ud83e\udd14"
>>> print(json.dumps(input, ensure_ascii=False))
"foo\nbar🤔"

So I think that's the right way forward. I will make an update to the draft.

eshryane commented 2 years ago

Brilliant, thanks @mxsasha

mxsasha commented 2 years ago

Serial issue is addressed in 874d812 which is already on main, opened #24 for encoding changes.

eshryane commented 2 years ago

@mxsasha The snapshot version in the examples in 874d812 is "3" and not "1", is this deliberate? I was expecting the first snapshot to have version "1" as the spec states The server MUST generate a snapshot for version number one.

mxsasha commented 2 years ago

@mxsasha The snapshot version in the examples in 874d812 is "3" and not "1", is this deliberate? I was expecting the first snapshot to have version "1" as the spec states The server MUST generate a snapshot for version number one.

Yes, it is deliberate. The intent here is that the snapshot in the Update Notification File is / may not be the first snapshot, there is periodic regeneration of the snapshot. And only one snapshot is in the file at the same time.

eshryane commented 2 years ago

Yes, it is deliberate. The intent here is that the snapshot in the Update Notification File is / may not be the first snapshot, there is periodic regeneration of the snapshot. And only one snapshot is in the file at the same time.

OK, understood. So the example will contain one snapshot at version "3" and deltas with versions before, same as, and after the snapshot.