Subject: [IPsec] IP-TFS YANG and MIB Updated

From: Don Fedyk <[email-masked]>
Date: Fri, 12 Nov 2021 12:18:38 +0000

Hi

We have updated the IP Traffic Flow Security YANG and MIB drafts to add management controls that reflect the IP-TFS discussions and changes from the meeting this week.  The updated drafts and the diffs are available at the usual place:

https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-yang-iptfs-03.txt

https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-mib-iptfs-01.txt

As always, comments welcome
Thanks
Don & Authors

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Nov 2021 21:21:01 +0200

> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-yang-iptfs-03.txt

While answering the shepherd writeup question "Briefly describe the
review of this document that was perfmed by the Document Shepherd", I
had to read this document too, so here are some of my comments to this
document: 

----------------------------------------------------------------------

         leaf dont-fragment {
           type boolean;
           default "false";
           description
             "Disable packet fragmentation across consecutive iptfs
              tunnel packets";

My understanding this only disables small packet fragmentation between
two outer fragments, i.e., does not disable it when the inner packet
is so big it does not fit on the outer packet?

If so adding text "Inner packets that does not fit to outer packets
will always be fragmented regardless of this setting, but if
dont-fragment is true those fragments do not include any other inner
packets".

Or if it is other way then add text saying "If this is true then inner
packets that are larger than what can be tranmitted in outer packets
will be dropped.".

----------------------------------------------------------------------

I would suggest adding text to some settings telling whether they
affect transmission or receive.

My understanding is that outer-packet-size, tunnel-rate,
dont-fragment, and max-aggregation-time are for transmission end.

window-size, send-immediately and lost-packet-timer-interval are for
the receiver end.

Some of those do have the text that explains this clearly, but some of
them do not. And then there are settings which affect both, i.e., I
think congestion-control is such.

Having clear text whether it affects transmission, reception or both
in description would make things easier to understand.

----------------------------------------------------------------------

Add comment to the lost-packet-timer-interval to say that "If not
using send-immediately then each lost packet will be delayed until
this expires", or something like that.

It is important that adminstrators understand that this will affect
delay visibile through the system.

----------------------------------------------------------------------

Add text to the security considerations section that as IPTFS tries to
hide the traffic flows through the network, then of course to be able
to read yang/mib statistics of the traffic flows is bad idea...

I.e., even read only access to the IPTFS statistics can be used to
find out traffic patterns.

> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-mib-iptfs-01.txt

Same changes than in Yang document is needed here too.

Also remove the last sentence of the abstract, i.e. I do not think
there is no need to say "This is an unpublished work in progress.",
in internet drafts, as they are working documents anyways... 
-- 
[email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Sun, 14 Nov 2021 04:34:45 -0500

> had to read this document too, so here are some of my comments to this

It means what the description says, which is dont fragment. This option was added early on based on comments from Valery indicating that some simple implementations would not want to support reassembly.

> packets that are larger than what can be tranmitted in outer packets

"Disable packet fragmentation across consecutive iptfs tunnel packets; inner packets larger than what can be transmitted in outer packets will be dropped.";

Yes.

> window-size, send-immediately and lost-packet-timer-interval are for

Right.

> in description would make things easier to understand.

Seems reasonable to me.

OK.

Good point.

> in internet drafts, as they are working documents anyways...

Thanks,
Chris.

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 14 Nov 2021 16:31:32 +0200

Christian Hopps writes:
> "Disable packet fragmentation across consecutive iptfs tunnel
> packets; inner packets larger than what can be transmitted in outer
> packets will be dropped.";

That is good. 

> > in internet drafts, as they are working documents anyways...

As I sent already in my private email the mib document also needs the
IANA considerations section and splitting references to normative and
informative.

And the Security Considerations section of MIB document needs to use
the MIB security considerations boilerplate as described in
https://trac.ietf.org/trac/ops/wiki/mib-security page.

(Just repeating these important points here so they do not get lost,
as I earlier only sent them to authors).
-- 
[email-masked]

---

From: Don Fedyk <[email-masked]>
Date: Tue, 16 Nov 2021 20:08:57 +0000

Hi 

Thanks for the comments and feedback.  I have uploaded versions to address the comments on both the YANG and corresponding MIB document.  

Don

-----Original Message-----
From: Tero Kivinen <[email-masked]> 
Sent: Sunday, November 14, 2021 9:32 AM
To: Christian Hopps <[email-masked]>
Cc: Don Fedyk <[email-masked]>; [email-masked]
Subject: Re: [IPsec] IP-TFS YANG and MIB Updated

Christian Hopps writes:
> > Or if it is other way then add text saying "If this is true then 
> > inner packets that are larger than what can be tranmitted in outer 
> > packets will be dropped.".
> 
> "Disable packet fragmentation across consecutive iptfs tunnel packets; 
> inner packets larger than what can be transmitted in outer packets 
> will be dropped.";

That is good. 

> > in internet drafts, as they are working documents anyways...

As I sent already in my private email the mib document also needs the IANA considerations section and splitting references to normative and informative.

And the Security Considerations section of MIB document needs to use the MIB security considerations boilerplate as described in https://trac.ietf.org/trac/ops/wiki/mib-security page.

(Just repeating these important points here so they do not get lost, as I earlier only sent them to authors).
--
[email-masked]