Re: [OPSEC] New Version Notification for draft-sriram-opsec-urpf-improvements-03.txt

[Sriram, Kotikalapudi (Fed)]

[Posting on OPSEC and GROW lists. There has been interest in this work in GROW 
also.]

We (the authors) have gone through the draft carefully once again 
and made significant edits/rewrites  to carefully address the comments 
we received in the OPSEC meeting in Prague last summer and to make the draft 
read better.

https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-03 
Diff: 
https://tools.ietf.org/rfcdiff?url2=draft-sriram-opsec-urpf-improvements-03.txt

Now the document specifies the two algorithms clearly: 
(1) for the not so challenging customer cone scenario (Algorithm A in Section 
3.1.1); and
(2) for the challenging customer cone scenario (Algorithm B in Section 3.4).
Also, Section 3.6 (Summary of Recommendations) is new.

We've requested the chairs for a slot in OPSEC meeting in London to give an 
update.
We look forward to additional comments/discussion on the list anytime,
and also in person in London. 

Thanks.
Sriram

From: internet-dra...@ietf.org 
Sent: Monday, March 5, 2018 6:19 PM
To: Sriram, Kotikalapudi (Fed); Montgomery, Douglas (Fed); Jeffrey Haas
Subject: New Version Notification for 
draft-sriram-opsec-urpf-improvements-03.txt

A new version of I-D, draft-sriram-opsec-urpf-improvements-03.txt
has been successfully submitted by Kotikalapudi Sriram and posted to the
IETF repository.

Name:   draft-sriram-opsec-urpf-improvements
Revision:   03
Title:  Enhanced Feasible-Path Unicast Reverse Path Filtering
Document date:  2018-03-05
Group:  Individual Submission
Pages:  15

https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-03 

Abstract:
   This document identifies a need for improvement of the unicast
   Reverse Path Filtering techniques (uRPF) [BCP84] for source address
   validation (SAV) [BCP38].  The strict uRPF is inflexible about
   directionality, the loose uRPF is oblivious to directionality, and
   the current feasible-path uRPF attempts to strike a balance between
   the two [BCP84].  However, as shown in this draft, the existing
   feasible-path uRPF still has short comings.  This document describes
   an enhanced feasible-path uRPF technique, which aims to be more
   flexible (in a meaningful way) about directionality than the
   feasible-path uRPF.  It can potentially alleviate ISPs' concerns
   about the possibility of disrupting service for their customers, and
   encourage greater deployment of uRPF techniques.

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt

[Ines Robles]

I agree with you Fernando,
thanks,
ines

On Mar 6, 2018 15:11, "Fernando Gont"  wrote:

On 03/06/2018 05:47 AM, Ines Robles wrote:
> Hi Fer,
>
>
> On 06.03.2018 10:36, Fernando Gont wrote:
>> [RFC] represents this document.
>>
>>Hex Value  Binary Value
>>   act  chg  rest Description  Reference
>>-  ---  ---  ---  -   --
>> 0x23  001   00011   RPL Option[RFC]
>> 0x63  011   00011   RPL Option(DEPRECATED) [RFC6553][RFC]
>>
>>
>> SO, while you don't say that elsewhere, it would seem to me that you
>> *are* deprecating it?
> Ah Ok, I understand, so yes, we deprecated the value of 0x63, but not
> the option, so what about to say:
>
> Something like: "
>
>  This option was originally specified in [RFC6553 <
https://tools.ietf.org/html/rfc6553>]. [I-D.ietf-roll-useofrplinfo
> ] updates the registration made
in [RFC6553 ] Destination
>Options and Hop-by-Hop Options registry from 0x63 to 0x23."
>
> or
>
> " This option was originally specified in [RFC6553 <
https://tools.ietf.org/html/rfc6553>].  The value of 0x63 has been
>deprecated by [I-D.ietf-roll-useofrplinfo
> ], which proposes a new value
(0x23) for the RPL Option."

I like this second option. But will say "specifies" (rather than
"proposes"), since by the time this doc is published,
I-D.ietf-roll-useofrplinfo whould have been published already.

Thoughts?

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt

[Fernando Gont]

On 03/06/2018 05:47 AM, Ines Robles wrote:
> Hi Fer,
> 
> 
> On 06.03.2018 10:36, Fernando Gont wrote:
>> [RFC] represents this document.
>>
>>Hex Value  Binary Value
>>   act  chg  rest Description  Reference
>>-  ---  ---  ---  -   --
>> 0x23  001   00011   RPL Option[RFC]
>> 0x63  011   00011   RPL Option(DEPRECATED) [RFC6553][RFC]
>>
>>
>> SO, while you don't say that elsewhere, it would seem to me that you
>> *are* deprecating it?
> Ah Ok, I understand, so yes, we deprecated the value of 0x63, but not
> the option, so what about to say:
> 
> Something like: "
> 
>  This option was originally specified in [RFC6553 
> ]. [I-D.ietf-roll-useofrplinfo
> ]
>  updates the registration made in [RFC6553 
> ] Destination
>Options and Hop-by-Hop Options registry from 0x63 to 0x23."
> 
> or
> 
> " This option was originally specified in [RFC6553 
> ].  The value of 0x63 has been
>deprecated by [I-D.ietf-roll-useofrplinfo
> ],
>  which proposes a new value (0x23) for the RPL Option." 

I like this second option. But will say "specifies" (rather than
"proposes"), since by the time this doc is published,
I-D.ietf-roll-useofrplinfo whould have been published already.

Thoughts?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt

[Mikael Abrahamsson]

On Mon, 5 Mar 2018, Fernando Gont wrote:


Folks,

This rev is meant to address your feedback regarding opt 0x23
(draft-ietf-roll-useofrplinfo).

Please do let us know if your concerns have been addressed.


(re-)Read document in its entirety and this is what came to mind:

3.4.1.4, I've made this error (at least) once, can we have a link and 
short explanation what a "jumbogram" is? Just so people (like me) don't 
get them mixed up with jumbo frame? (I realise this is in 4.3.3, but 
adding a link here might still help)


3.5. Can we add a "(yet)" as in "have not (yet) been assigned" ?

3.5.4 The second paragraph is really important, can we emphasise this a 
bit more? Or even break it out into a separate item in the list?


3.5.5 What about adding a sentence that devices should have configuration 
option to allow EHs based on codepoints so that older software can be made 
to allow EHs that are not known to that software at the point of compile? 
Also applies to 4.4.4


4.3.2.5 here it says "should not discard" and in other items it says 
"should permit". Would help if this is done in the same way throughout the 
document?


I just noticed that a lot of the paragraph headers contain the word 
"Blocked". This is first mentioned in 3.4.1.4 and it's never mentioned 
earlier in the document together with what "discarded", "filtered", 
"rejected" means.


4.4.5 what does "enterprise" mean here? Perhaps another term can be used, 
such as "very security conscious" or something like that?




--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt

[Ines Robles]

Hi Fer,


On 06.03.2018 10:36, Fernando Gont wrote:

[RFC] represents this document.

Hex Value  Binary Value
   act  chg  rest Description  Reference
-  ---  ---  ---  -   --
 0x23  001   00011   RPL Option[RFC]
 0x63  011   00011   RPL Option(DEPRECATED) [RFC6553][RFC]


SO, while you don't say that elsewhere, it would seem to me that you
*are* deprecating it?
Ah Ok, I understand, so yes, we deprecated the value of 0x63, but not 
the option, so what about to say:


Something like: "

 This option was originally specified in [RFC6553 ]. [I-D.ietf-roll-useofrplinfo 
] updates the registration made in [RFC6553 ] Destination

   Options and Hop-by-Hop Options registry from 0x63 to 0x23."

or

" This option was originally specified in [RFC6553 
].  The value of 0x63 has been
   deprecated by [I-D.ietf-roll-useofrplinfo 
], which proposes a new value (0x23) for the RPL Option."


What do you think?

Thanks,

Ines.




Thanks!

Best regards,


___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt

[Fernando Gont]

Hola, Ines,

On 03/06/2018 05:32 AM, Ines Robles wrote:
> Hi Fernando,
> 
> Thank you very much for the updated document. It looks good to me,
> 
> Just a comment:
> 
> where states  "...This option was originally specified in [RFC6553
> ]. It has been deprecated by
> [I-D.ietf-roll-useofrplinfo
> ]."
> 
> I would replace "deprecated" by "updated", since the roll-I-D updates
> the RPL Option with a new value. What do you think?

My description was based on the "IANA Considerations" of your document,
which says:


[RFC] represents this document.


   Hex Value  Binary Value
  act  chg  rest Description  Reference
   -  ---  ---  ---  -   --
0x23  001   00011   RPL Option[RFC]
0x63  011   00011   RPL Option(DEPRECATED) [RFC6553][RFC]


SO, while you don't say that elsewhere, it would seem to me that you
*are* deprecating it?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt

[Ines Robles]

Hi Fernando,

Thank you very much for the updated document. It looks good to me,

Just a comment:

where states  "...This option was originally specified in [RFC6553 
]. It has been deprecated by 
[I-D.ietf-roll-useofrplinfo 
]."


I would replace "deprecated" by "updated", since the roll-I-D updates 
the RPL Option with a new value. What do you think?


Thanks,

Ines.


On 06.03.2018 03:22, Fernando Gont wrote:

Folks,

This rev is meant to address your feedback regarding opt 0x23
(draft-ietf-roll-useofrplinfo).

Please do let us know if your concerns have been addressed.

Thanks!

Cheers,
Fernando




On 03/05/2018 08:31 PM, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operational Security Capabilities for IP 
Network Infrastructure WG of the IETF.

 Title   : Recommendations on the Filtering of IPv6 Packets 
Containing IPv6 Extension Headers
 Authors : Fernando Gont
   Will(Shucheng) Liu
Filename: draft-ietf-opsec-ipv6-eh-filtering-05.txt
Pages   : 35
Date: 2018-03-05

Abstract:
It is common operator practice to mitigate security risks by
enforcing appropriate packet filtering.  This document analyzes both
the general security implications of IPv6 Extension Headers and the
specific security implications of each Extension Header and Option
type.  Additionally, it discusses the operational and
interoperability implications of discarding packets based on the IPv6
Extension Headers and IPv6 options they contain.  Finally, it
provides advice on the filtering of such IPv6 packets at transit
routers for traffic *not* directed to them, for those cases in which
such filtering is deemed as necessary.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-05
https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-eh-filtering-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec





___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec