EPIC-HP as a Hop-by-Hop extension option

[matzf]

Currently, EPIC-HP is implemented as a separate path type (PathType field value 3). As described in the documentation, this path type is defined by four 4-byte fields (timestamp, counter, and and two hop verification fields), followed by the normal SCION path.

This could be implemented as a Hop-by-Hop extension option and using the normal SCION path type. The extension option would contain the additional fields. The routers two last routers on a path could, if they choose to implement EPIC-HP, check if the extension option is present and process it. Any other router just processes the normal SCION path.

The advantages/disadvantages are:

• :heavy_minus_sign: 4 byte overhead for Hop-by-Hop extension header and TLV option header
• :heavy_minus_sign: more work for downstream systems (duplicate suppression system) to extract the EPIC-HP fields (search for option type)
• :heavy_plus_sign: fewer path types to support (in routers, applications, tools, etc.)
• :heavy_plus_sign: EPIC-HP supported in transit routers without explicitly implementing the EPIC-HP path type

One additional point is the handling of reverse paths with EPIC-HP; for reversing a path with EPIC-HP path type, additional information would be required to add valid HVFs for the reverse direction. As this is not usually available, the reverse path is "downgraded" to a normal SCION path instead. An EPIC-HP implementation based an extension option would handle this more naturally. The reverse path would just be the normal SCION path and a reply packet would naturally not include the extension option, unless it is explicitly added.

Summary

EPIC-HP appears to be ideal for an implementation in an extension header option, as it just adds additional fields that need to be processed by some routers along the path. Yes, compared to a separate path type, there is some overhead in terms of header size and parsing, but perhaps the point is; If the hop-by-hop extension is not good enough for this use case, when would we ever use it?

[sgmonroy]

I think you forgot to mention that now all routers in the path need to check whether they need to process the HBH extension or not.

This "path" is quite peculiar in the sense that only two routers in the path would care about the extra fields compared to the standard SCION path, but I still think it is not a HBH extension. The down side of having it as a path type is clear, all routers need to be able to process the path type. That said, this "type" seems to be the exception, and looking at other types, ie. EPIC level 2+, COLIBRI, would need router updates to process them.

Just to be clear, I don't think this as a path type is great either, but it is more consistent. There are other ways you could provide this functionality, but I don't think there is a clear hands down winner in any case:

1. Use E2E extension and have routers with HP enabled on those interfaces to parse the E2E looking for the HP extension. - pros: no router updates needed for routers along the path, no extra parsing. - cons: routers processing E2E extensions, which in paper should not happen.
2. Provide HP as a next header and similarly to the E2E, have routers with HP enabled to only accept packets with next header HP. - pros: no router updates needed for routers along the path, no extra parsing. - cons: could be argued it should not be a "protocol" on its own.

[matzf]

Thanks for the reply @sgmonroy.

I think you forgot to mention that now all routers in the path need to check whether they need to process the HBH extension or not.

This is not accurate. Only the routers last two routers along the path, i.e. those that want to process the option to verify the EPIC fields, need to check for the existence of the corresponding HBH option. It would be correct to say that any router that wants to process some other HBH extension option would need to skip the EPIC option while looking for the options it's actually interested in. But I don't think it would be fair to attribute this extra effort of skipping to the EPIC HBH option, and as we currently don't have any HBH option support it's currently just not an issue.

I don't quite see a reason why HBH Extensions should be reserved for use cases where every router along the path needs to process the options. If what I described above is not sufficient, because we do not want the overhead of checking for the existence of the HBH option even for the last two routers, I think one additional option to your suggestions would be to use the router alert flag; we could generally say that HBH are only processed by routeres if the alert flag is set.

[matzf]

With the newly proposed EPIC-SAPV system (see #4110), with yet another path type, I think having this discussion is still very relevant. The main argument in favor of using a separate path type for this is that this allows to cut off and re-use four bytes of the hop-field-MAC field, which is arguably a neat trick. However, defining new path types will incur a cost at the entire SCION "ecosystem". Every SCION component, routers, libraries, applications, tools, middleboxes,etc. MUST implement these path types in order to be even minimally compatible. The system making use of a separate path type can only be usable if the path type is supported by every component along a path. The designated extension mechanism avoids these pitfalls. Extension options can always easily be skipped and the default processing for the packet can be unaffected. Importantly, systems making use of extension options will naturally have to deal with partial support for a new option, making it more likely that even a partially deployed system can be useful.

I'm not saying that we should never define new path types -- being able to do so appears like a very powerful option. However, I think the very strong default for new systems should be to rely on the extension header mechanism as far as possible. Once this has been explored, and the system is well understood and all the trade offs are clear, and there are strong disadvantages from using extension headers, then maybe adding a new path type can be considered.

P.s. Btw. this also applies to Colibri, but that discussion is just so much more complicated...

[lukedirtwalker]

@matzf I think @sgmonroy provided a very nice alternative to what you suggest:

Provide HP as a next header and similarly to the E2E, have routers with HP enabled to only accept packets with next header HP.

• pros: no router updates needed for routers along the path, no extra parsing.
• cons: could be argued it should not be a "protocol" on its own.

I would actually for such a solution and agree that if we don't really need to create a new path type we should not.

[matzf]

@lukedirtwalker Thanks for your reply. I don't remember why I didn't reply to this proposal specifically, but I agree, this looks like a better solution than the separate path type.

In essence, this would amount to defining a separate extension header type. Is your idea that this new extension header would then also contain TLV encoded options, or would this be specific to EPIC? Can you explain why you would think this is more appropriate than putting the EPIC data as an option into the existing Hop-by-Hop extension header? I had always been thinking of the HBH-extension as quite generic container for all kinds of extension options to be processed by routers -- do you have something more specific in mind, then? Do you have some examples for options that you should be added to the HBH extension (there are none defined yet)?