Re: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

[Fred Baker <[e-mail]>]

Happy to be wrong, but I think we already have those. From the security header on, any network device should assume that the message content is (or may be) encrypted, and make no policy requirements beyond that point. If a message contains no security header but policy makes a network device stop where it might be found, I think we have achieved the goal.

Sent from my iPad

> On Feb 22, 2021, at 11:17 AM, Tom Herbert <[e-mail]> wrote:
> 
> On Mon, Feb 22, 2021 at 11:14 AM Fernando Gont <[e-mail]> wrote:
>> 
>> Tom,
>> 
>>> On 22/2/21 13:29, Tom Herbert wrote:
>>> On Mon, Feb 22, 2021 at 8:23 AM Nick Hilliard <[e-mail]> wrote:
>>>> 
>> [....]
>>> I understand the purpose of the draft, however, IMO, for the problems
>>> that are described there is insufficient detail and scope to draw any
>>> meaningful conclusions or take away any new insights.
>> 
>> Then I guess we disagree. One of the most commonly questions asked in
>> this contact is "But... why do routers look inside packets?" -- and this
>> document answers that question, along with the challenges it represents.
>> 
>> Note: in a thread on specific transports you also asked what information
>> routers process. And this document also answers such question.
>> 
> Fernando,
> 
> If you recall, I specifically asked for the _normative_ requirements
> about what a host must expose to the network beyond just the IP
> headers. If the normative requirements are such that that hosts MUST
> expose transport ports (assuming consensus is achieved for that), then
> it follows that we'll need the normative requirements for how deep in
> the packet those transport headers can be.
> 
> Tom
>> 
>> 
>>> When the draft
>>> mentions that routers might drop packets because packets are too long,
>>> then the obvious question is what exactly is too long.
>> 
>> And the obvious answer is that that depends on a vendor/model basis. If
>> the router only copies the mandatory header to a buffer, then "too long"
>> might be "1 EH".
>> 
>> 
>>> Since this
>>> draft is discussing real implementation and not theory, it seems like
>>> measuring the extent and determining the real operational parameters
>>> of the problems, like what a useful minimum length of header chains
>>> is, seems straightforward either by experimentation or simply polling
>>> router vendors to see what they support.
>> 
>> It performs a qualitative analysis of the problem.
>> 
>> What you ask seems to be either RFC7872bis, or a document that would
>> complement RFC7872.
>> 
>> ... but certainly out of the scope of this document.
>> 
>> 
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: [e-mail]
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> 
>> 
>> 
>>