Re: [Anima] SecDir review of draft-ietf-anima-grasp-09

[Barry Leiba]

> > Personal opinion: encryption should be a MUST.
>
> I believe that we will have situations where we have a secured ACP into a NOC
> (to an edge router or VM hypervisor), and then we will have some unencrypted,
> but secured links to platforms in transition.
>
> It will be easy to add the GRASP daemon to answer resource requests to the
> platform, but hard to add the ACP to that platform without a forklift
> upgrade.
>
> This is why I think it is a SHOULD, as much as I want it to transition to
> being a MUST.

This brings up a common rant that I have:
We should be putting into our protocol specs what we want the protocol
to be, not some compromise that comes from knowing that not everyone
will comply with everything from the start.

If the right thing is to say "MUST encrypt", but we know there'll be a
transition period during which that's not fully practical, then we
should say that.  Something like this added to Section 3.5.1:

NEW
In some cases there will be a transition period, in which it might not
be practical to run with strong encryption right away.  It's important
to keep this period as short as possible, and to upgrade to a fully
encrypted setup as soon as possible.
END

> > Once we specify byte-by-byte comparison, do we need to worry about this
> > in a protocol document? If someone is silly enough to specify an
>
> It matters, when humans have to confirm things.  I think that objectives
> will be mostly baked into code.  So, I agree with you, but I would rather
> exclude all that UTF stuff too.

That's true: if these really are protocol elements and there's no need
to have them Internationalized for human consumption, perhaps limiting
them to US-ASCII makes sense and avoids issues with odd character
effects (code that breaks if certain characters appear in strings, or
humans debugging things and being confused by characters that look the
same but are encoded differently).  On the other hand, if it really
would be handy to be able to define objective names in Chinese, Hindi,
or Hebrew, there's nothing wrong with sticking to UTF-8 as long as the
possibilities are understood and folks are OK with it.

Barry

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] GRASP vs ASA negotiation (was Re: concerns about selection of session-id in GRASP messages)

[Michael Richardson]

Please excuse time-warp mail: trying to hit zero inbox...
[so you'd better not reply! :-)]

I think that my point below is not contradicted by any text, I just wanted to
close the loop on this thread. At least close it in my mind.

Brian E Carpenter  wrote:
>> 2) the response from a multicast DISCOVERY is a unicast TCP
>> connection.  (We've discussed this before, and I'm okay with it, but I
>> still wonder if it will be well received.)
>>
>> Is there any reason why the TCP connection for the reply has to be
>> from the GRASP "kernel"/"core" daemon?  Could the GRASP daemon pass
>> the enquiry to the ASA itself, and the ASA could connect to the thing
>> that is asking, and reply with the M_RESPONSE itself?

> In my opinion, no. ASAs are the apps of an autonomic network and won't
> be written by protocol geeks. The actual ASA should simply register
> itself with GRASP and indicate that it's available for discovery; it
> will be some daemon inside GRASP that handles discovery. I think any
> other implementation model is unreasonable: we're hoping there will be
> 100s or 1000s of ASAs. (However, some of GRASP will be a user space
> library, as Toerless pointed out ages ago and as the API draft
> indicates.)

I share your view: ASAs need to be the apps of autonomic networking.
Quite literally that is a good model to take, and I hope someone takes this
view.  The whole android model: Java/Dalvik/ART, IDE, very low latency IPC,
and isolation between ASA by default.  Router Control plane CPUs are probably
still underpowered compared to today's smartphones, but  are still in the
same category.

My recent understanding is that the M_RESPONSE is just about where the ASA
is.  That the thing asking would still need to initiate a TCP GRASP
connection to the ASA to do the M_SYN_NEG process.   What I was thinking was
that if the M_RESPONSE was sent by the responding ASA, then it could continue
to use the TCP connection that was already up.

It isn't a TCP connection setup that I'm trying to avoid, (that's a really
minor saving) but rather it permits load balancing of the ASA function at
discovery time, rather than a TCP SYN time.   And if the ASA is located in
the NOC, it permits the NOC to do outgoing TCP connections, rather than
accept incoming ones.

In my thinking, the core/kernel GRASP daemon then functions much like inetd
did in Unix systems of yore (systemd has tried to replace this).

> It would be a protocol change, since there's no way to signal that at
> the moment. Is it really useful? (It would probably be a new locator
> option, like locator-option /= [O_SAME_LOCATOR]). But it would only
> work in compressed implementation where the ASA and GRASP are tightly
> integrated.

I clearly did not explain this well enough, because you concluded the
opposite of what I was thinking.  It would be used in the opposite situation
where GRASP spawned the ASA, passed it the M_DISCOVERY message to reply to.
When I say "spawned", it could be a process, or a complete container,
maybe a full VM.

It might even have a different IP address, although at that point I consider
that really, the GRASP daemon has just relayed the M_DISCOVERY to a very
limited GRASP instance running inside the ASA.  This might be the best way to
think of the architecture that I'm thinking of anyway.  That's why I wrote,
above, it doesn't really affect the protocol.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] CRLs in iDevID manufacturer signing certs?

[Eliot Lear]

Hi,

What is the thinking on including CRL pointer in the manufacturer
signing cert?  This question came up in industry discussions.

Eliot




signature.asc
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] SecDir review of draft-ietf-anima-grasp-09

[Michael Richardson]

Brian E Carpenter  wrote:
>> Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST?
>> Looking ahead to 3.5.2.1, how could it be considered safe to use a
>> network configuration protocol across administrative boundaries
>> without encryption?

> Input please, or else you will see this as an open issue in Chicago.

> Personal opinion: encryption should be a MUST.

I believe that we will have situations where we have a secured ACP into a NOC
(to an edge router or VM hypervisor), and then we will have some unencrypted,
but secured links to platforms in transition.

It will be easy to add the GRASP daemon to answer resource requests to the
platform, but hard to add the ACP to that platform without a forklift
upgrade.

This is why I think it is a SHOULD, as much as I want it to transition to
being a MUST.

>> The other question is whether there are any restrictions on what
>> Unicode characters can be represented.  You make the colon a special
>> character but give no other restrictions, so an objective name could
>> include space characters (and various related Unicode characters such
>> as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER),
>> control characters (FORM FEED, CARRIAGE RETURN, and the like),

> Once we specify byte-by-byte comparison, do we need to worry about this
> in a protocol document? If someone is silly enough to specify an

It matters, when humans have to confirm things.  I think that objectives
will be mostly baked into code.  So, I agree with you, but I would rather
exclude all that UTF stuff too.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] CRLs in iDevID manufacturer signing certs?

[Kent Watsen]

My view is that, if the IDevID has a CRL/OCSP URL listed, then the
validator SHOULD do the checking.  If the vendor didn't actually
want revocation checking done, then the vendor should've excluded
such information from their IDevID certs.

FWIW, 802.1AR takes a much neutral stance in Section 6.5.3 (Validation of 
DevIDs):

  The DevID is an X.509 credential and can be validated using the
  RFC 5280 defined mechanisms. IDevIDs are intended to have very
  long validity periods even exceeding what would normally be
  cryptographically acceptable. The manufacturer is not required
  to provide a Certificate Revocation List (CRL) although the
  validator may do CRL checking if the manufacturer provides CRLs.
  The validator may verify CRLs for LDevIDs as necessary.

Kent


-ORIGINAL MESSAGE-

Thanks, Kent.  Then it seems to me that we have a MAY floating around
for CRL checking on the part of the registrar for BRSKI.  Right?

Eliot


On 3/9/17 7:25 PM, Kent Watsen wrote:
> Hi Elliot,
>
>
>> What is the thinking on including CRL pointer in the manufacturer
>> signing cert?  This question came up in industry discussions.
> 802.1AR says that the IDevID secrets must be stored confidentially and be not 
> available outside the module.  In practice, a crypto processor with 
> tamper-resistant NVRAM is used (e.g., TPM).  As such, the likelihood of the 
> credentials being stolen/discovered are near zero, but it is not zero, as a 
> determined adversary with sufficient resources can still have their way with 
> it.  Still, vendors will likely conclude that protecting against that level 
> of attack isn't necessary.  That said, vendors face a more likely scenario, 
> of issues occurring by contract manufacturers, whether it be accidental or 
> intentional.  And as unlikely this scenario may seem, things happen and the 
> vendor would be without recourse if unable to issue revocations.  To this 
> extent, setting up the infrastructure to support revocations can be compared 
> to insurance - hopefully you never need it, but when you do, you're glad you 
> have it.
>
> Kent
>
>
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] CRLs in iDevID manufacturer signing certs?

[Kent Watsen]

Hi Elliot,


> What is the thinking on including CRL pointer in the manufacturer
> signing cert?  This question came up in industry discussions.

802.1AR says that the IDevID secrets must be stored confidentially and be not 
available outside the module.  In practice, a crypto processor with 
tamper-resistant NVRAM is used (e.g., TPM).  As such, the likelihood of the 
credentials being stolen/discovered are near zero, but it is not zero, as a 
determined adversary with sufficient resources can still have their way with 
it.  Still, vendors will likely conclude that protecting against that level of 
attack isn't necessary.  That said, vendors face a more likely scenario, of 
issues occurring by contract manufacturers, whether it be accidental or 
intentional.  And as unlikely this scenario may seem, things happen and the 
vendor would be without recourse if unable to issue revocations.  To this 
extent, setting up the infrastructure to support revocations can be compared to 
insurance - hopefully you never need it, but when you do, you're glad you have 
it.

Kent



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] CRLs in iDevID manufacturer signing certs?

[Eliot Lear]

Thanks, Kent.  Then it seems to me that we have a MAY floating around
for CRL checking on the part of the registrar for BRSKI.  Right?

Eliot


On 3/9/17 7:25 PM, Kent Watsen wrote:
> Hi Elliot,
>
>
>> What is the thinking on including CRL pointer in the manufacturer
>> signing cert?  This question came up in industry discussions.
> 802.1AR says that the IDevID secrets must be stored confidentially and be not 
> available outside the module.  In practice, a crypto processor with 
> tamper-resistant NVRAM is used (e.g., TPM).  As such, the likelihood of the 
> credentials being stolen/discovered are near zero, but it is not zero, as a 
> determined adversary with sufficient resources can still have their way with 
> it.  Still, vendors will likely conclude that protecting against that level 
> of attack isn't necessary.  That said, vendors face a more likely scenario, 
> of issues occurring by contract manufacturers, whether it be accidental or 
> intentional.  And as unlikely this scenario may seem, things happen and the 
> vendor would be without recourse if unable to issue revocations.  To this 
> extent, setting up the infrastructure to support revocations can be compared 
> to insurance - hopefully you never need it, but when you do, you're glad you 
> have it.
>
> Kent
>
>
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>




signature.asc
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] SecDir review of draft-ietf-anima-grasp-09

[Brian E Carpenter]

On 10/03/2017 05:53, Barry Leiba wrote:
>> > Personal opinion: encryption should be a MUST.
>>
>> I believe that we will have situations where we have a secured ACP into a NOC
>> (to an edge router or VM hypervisor), and then we will have some unencrypted,
>> but secured links to platforms in transition.
>>
>> It will be easy to add the GRASP daemon to answer resource requests to the
>> platform, but hard to add the ACP to that platform without a forklift
>> upgrade.
>>
>> This is why I think it is a SHOULD, as much as I want it to transition to
>> being a MUST.
> 
> This brings up a common rant that I have:
> We should be putting into our protocol specs what we want the protocol
> to be, not some compromise that comes from knowing that not everyone
> will comply with everything from the start.
> 
> If the right thing is to say "MUST encrypt", but we know there'll be a
> transition period during which that's not fully practical, then we
> should say that.  Something like this added to Section 3.5.1:
> 
> NEW
> In some cases there will be a transition period, in which it might not
> be practical to run with strong encryption right away.  It's important
> to keep this period as short as possible, and to upgrade to a fully
> encrypted setup as soon as possible.
> END

or perhaps more precisely:

During initialization of nodes there will be a transition period...

Whether this is phrased as an exception to the MUST or as the justification
for ignoring the SHOULD is a matter of taste, I think.

> 
>> > Once we specify byte-by-byte comparison, do we need to worry about this
>> > in a protocol document? If someone is silly enough to specify an
>>
>> It matters, when humans have to confirm things.  I think that objectives
>> will be mostly baked into code.  So, I agree with you, but I would rather
>> exclude all that UTF stuff too.
> 
> That's true: if these really are protocol elements and there's no need
> to have them Internationalized for human consumption, perhaps limiting
> them to US-ASCII makes sense and avoids issues with odd character
> effects (code that breaks if certain characters appear in strings, or
> humans debugging things and being confused by characters that look the
> same but are encoded differently).  On the other hand, if it really
> would be handy to be able to define objective names in Chinese, Hindi,
> or Hebrew, there's nothing wrong with sticking to UTF-8 as long as the
> possibilities are understood and folks are OK with it.

My thought was that these names will sometimes be visible to humans so why
not allow localized names? If GRASP succeeds it might be used for local
applications, not just generic applications. So I'd rather allow it
from the start, and if we have to add character-set restrictions later,
so be it.

Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] SecDir review of draft-ietf-anima-grasp-09

[Barry Leiba]

>> This brings up a common rant that I have:
>> We should be putting into our protocol specs what we want the protocol
>> to be, not some compromise that comes from knowing that not everyone
>> will comply with everything from the start.
>>
>> If the right thing is to say "MUST encrypt", but we know there'll be a
>> transition period during which that's not fully practical, then we
>> should say that.  Something like this added to Section 3.5.1:
>>
>> NEW
>> In some cases there will be a transition period, in which it might not
>> be practical to run with strong encryption right away.  It's important
>> to keep this period as short as possible, and to upgrade to a fully
>> encrypted setup as soon as possible.
>> END
>
> or perhaps more precisely:
>
> During initialization of nodes there will be a transition period...

Yep; better.

> Whether this is phrased as an exception to the MUST or as the justification
> for ignoring the SHOULD is a matter of taste, I think.

I don't think it's a question of taste.  If there's a long-term reason
to run nodes without encryption, then SHOULD might make sense.  But if
we do expect the stable state to always be encrypted, and avoiding it
is a short-term expedient that we want to have go away as soon as
possible, then the protocol should say MUST, and the exception is
clearly specified as a brief thing that mustn't last.  It's a
substantive difference, not one of writing style.

> My thought was that these names will sometimes be visible to humans so why
> not allow localized names? If GRASP succeeds it might be used for local
> applications, not just generic applications. So I'd rather allow it
> from the start, and if we have to add character-set restrictions later,
> so be it.

Makes sense to me.  Carry on.

Barry

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-03.txt

[Brian E Carpenter]

Hi,

We have made a few small updates to make the text more precise.
We believe this should be ready for WG Last Call as Informational.

Regards
   Brian + co-authors

On 10/03/2017 15:54, 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 Autonomic Networking Integrated Model and 
> Approach of the IETF.
> 
> Title   : Autonomic IPv6 Edge Prefix Management in 
> Large-scale Networks
> Authors : Sheng Jiang
>   Zongpeng Du
>   Brian Carpenter
>   Qiong Sun
>   Filename: draft-ietf-anima-prefix-management-03.txt
>   Pages   : 14
>   Date: 2017-03-09
> 
> Abstract:
>This document describes an autonomic solution for IPv6 prefix
>management at the edge of large-scale ISP networks.  An important
>purpose of the document is to use it for validation of the design of
>various components of the autonomic networking infrastructure.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-prefix-management-03
> 
> 
> 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/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] I-D Action: draft-ietf-anima-grasp-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and 
Approach of the IETF.

Title   : A Generic Autonomic Signaling Protocol (GRASP)
Authors : Carsten Bormann
  Brian Carpenter
  Bing Liu
Filename: draft-ietf-anima-grasp-10.txt
Pages   : 77
Date: 2017-03-09

Abstract:
   This document establishes requirements for a signaling protocol that
   enables autonomic nodes and autonomic service agents to dynamically
   discover peers, to synchronize state with them, and to negotiate
   parameter settings with them.  The document then defines a general
   protocol for discovery, synchronization and negotiation, while the
   technical objectives for specific scenarios are to be described in
   separate documents.  An Appendix briefly discusses existing protocols
   with comparable features.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-anima-grasp-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-10


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/

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima